TimesDates.jl dev for v2

Specific Domains
, ,
1

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?

4 Likes
3

A vote for _S.sssssssss to define the sub-second part down to nanosecond precision.

4

I think the _S.sssssssss is the better option, but I do wonder if there might be another way, perhaps _S.NS as a shortcut?

Using μs for microsecond for display/printing seems fine, but I think in any case where it requires user input \mu or u should be allowed.

5

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

2 Likes
6

I only meant that it would be nice if you could write it with a shortcut also, not that you wouldn’t support the explicit option. Same as what happens currently with y vs yyyy in dateformat""

1 Like
7

I too vote for ssssss

It is an actual issue in the wild as MySQL timestamps have 6dp

e.g. '2022-01-04 15:08:44.171540'

and DBInterface barfs on it

8

What is required
to properly (a) parse and (b) generate date_with_time strings
each in a simple and robust way
using an extended dateformat that supports submicrosecond values?

9

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?

10

New topic:
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.

  • DateTimeNanos (DateTimeNano)
  • DateNanoTimes (DateNanoTime)
  • NanoDates (NanoDate)
  • NanosecondDates (NanosecondDate or NanoDate)
  • DatesWithNanoseconds (any of the above)
1 Like
11

NanoDates (NanoDate) looks good.
NanoTimes (NanoTime) would also be easy to remember.

1 Like
12

I agree that NanoDates (NanoDate) is really good. It’s very distinct from other date/time packages, descriptive, and short.

13

Great thanks @rafael.guerra @Jordan_Cluts

14

I too thought NanoDates before I even saw your list of suggestions

we use nano-particles in regular speech rather than particle-nanos

15

:slightly_smiling_face:

16

never mind – revisiting

17

I am ready for some feedback.
The repo is NanoDates.jl
There are some docs linked in the README.

To give it a whirl,
add https://github.com/JeffreySarnoff/NanoDates.jl#main

18

Not yet documented is:

julia>

julia> using Dates, NanoDates

julia> using Dates: CompoundPeriod

julia> datetime = now(); date = Date(datetime);

julia> time = Time(datetime) + Microsecond(876) + Nanosecond(421);

julia> nd = NanoDate(date, time);

julia>

julia> date, time
(Date("2022-05-03"), Time(4, 28, 8, 774, 876, 421))

julia> nd
2022-05-03T04:28:08.774876421

julia>

julia> date
2022-05-03

julia> time
04:28:08.774876421

julia> datetime
2022-05-03T04:28:08.774

julia> nd
2022-05-03T04:28:08.774876421

julia>

julia> CompoundPeriod(date)
2022 years, 5 months, 3 days

julia> Date(ans)
2022-05-03

julia> CompoundPeriod(time)
4 hours, 28 minutes, 8 seconds, 774 milliseconds, 876 microseconds, 421 nanoseconds

julia> Time(ans)
04:28:08.774876421

julia> CompoundPeriod(datetime)
2022 years, 5 months, 3 days, 4 hours, 28 minutes, 8 seconds, 774 milliseconds

julia> DateTime(ans)
0000-01-01T04:28:08.774

julia> CompoundPeriod(nd)
2022 years, 5 months, 3 days, 4 hours, 28 minutes, 8 seconds, 774 milliseconds, 876 microseconds, 421 nanoseconds

julia> NanoDate(ans)
2022-05-03T04:28:08.774876421
1 Like
19

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.

20

actually, that is en route.

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)

using Dates, NanoDates
using Dates: format

nd_nanosecs = NanoDate(2022,5,3,12,15,30,123,456,789)
# 2022-05-03T12:15:30.123456789

df_nanosecs = dateformat"yyyy-mm-dd HH:MM:SS.sss"
# dateformat"yyyy-mm-dd HH:MM:SS.sss"

nd_nanosecs_str = format(nd_nanosecs, df_nanosecs)
# "2022-05-03 12:15:30.123456789"

nd_nanosecs_str2 = format(nd_nanosecs, df_nanosecs; sep=SmallWhiteCircle)
# "2022-05-03 12:15:30.123◦456◦789"
1 Like
21

The input looks odd: after the 30 seconds, we have milliseconds, microseconds and nanoseconds defined separately?

Wouldn’t it be more natural to input those as a single float, the fraction of seconds, as follows:

nd_nanosecs = NanoDate(2022,5,3, 12,15,30, 0.123456789)

Thank you.