I am working on a new version of TimesDates.jl using advancements that have become part of the Dates stdlib to simplify the implementation. Some of these improvements are accessible through non-exported specific elements of Dates.
Given the intent of this package: to offer a nanosecond resolved type that works just as does DateTime [and, separately, to offer nanosecond resolved TimeZones that works just as does ZonedDateTime ], accessing Dates internals seems reasonable to me. The opposing view is also reasonable, however under that view there is little impetus to rewrite – less improvement with more work.
I would welcome any snippets or notes pertaining to these details …
introducing characters ‘μ’, ‘n’ for a millisecond [nanosecond] digit
– @dateformat_str chokes on \mu (even with internal dict modifications)
would ‘c’ instead of ‘μ’ for millisecond digits be better?
extending dateformat to support submicrosecond values.
– e.g. dateformat"Y-m-dTH:M:S.sssμμμnnn" or “_S.sssssssss”
– what is required to support both sides of io?
fwiw I have used the _S.sssssssss in my own code and I like it better.
[one might use a shortcut … the expilict s’s correspond to the number of decimal digits to be honored (read or produced with correct rounding for time logic)
possible alternative, use '’ following the “S.” (e.g, "Y-m-dTH:M:S.") and interpret the ‘_’ to mean as many decimal digits as properly inform without misleading.]
resolved: allow 1,2…9 ‘s’ characters after the “S.”
(to allow 0 ‘s’ chars following “S.” is disclarifying, use “S”)
likely: allow ‘_’ after the “S.” should that fall out of other required time math logic
With regard to trailing 's’s in a DateFormat:
Current behavior in Dates is to accept _S.s, _S.ss, _S.sss and have them indicate the same behavior, use milliseconds. More than three 's’s throws an error. So how do we feel about coopting _S.ss and _S.sss to indicate milliseconds + microseconds and milliseconds+microseconds+nanoseconds, respectively?
I am working on revising the non-timezone supporting part of TimesDates first. This will be its own package, so people/software that does not require timezone support can have nanosecond resolution without the extra overhead of TimeZones.
I had wanted to name this TimeDates and follow-on timezone supporting part as ZonedTimeDates (which would use TimeDates). It has been decided that TimeDates is too close to TimesDates (and it is, I liked the name even so).
Lets choose the new name for the non-timezone supporting package rewrite (now happening). Do we want the exported type to be TimeDate for a one line edit for current packages using TimesDates? Or do we want an different type name, so there cannot be ambiguity conflicts when another used package itself uses TimesDates? I am inclined to go with the second as much as I would enjoy the first.
Some possible new package names (not in preference order) with the exported type in parens, suggest another if you like …
please express your preference.
This all looks so great. I am excited to be able to use this package going forward.
I looked through the existing documentation (and dug through the code) and it looks like at the moment there is no way to parse a string into a NanoDate like one can with DateTime using a DateFormat. I understand there is a lot of code that goes into making that work and it may not be considered in scope, or within the amount of time available. Just wondering if there is a plan to replicate such functionality?
Not a deal breaker of course as writing a custom function to convert a known string format into a NanoDate is not tremendously difficult.
Thanks for all the hard work you have put into making this package a reality!
Edit: Reread the first post of the thread where it was mentioned there is a desire to add this functionality.
here is the other half, making strings patterned on dateformats
(because the internal dateformat processing in Dates does not fully handle times at full resolution, there are limitations –
but they have – in important ways – been escorted away when doing what one likely wants with Nanosecond work)