# TimesDates.jl dev for v2
**URL:** https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377
**Category:** Specific Domains
**Tags:** dates, time, internals
**Created:** [March 24, 2022, 10:00am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377 "2022-03-24T10:00:08Z")
**Posts on this page:** 20
**Page:** 1
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [March 24, 2022, 10:00am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/1 "2022-03-24T10:00:08Z")
I am working on a new version of [TimesDates.jl](https://github.com/JeffreySarnoff/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?
---
### Author:  [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)
#### Post date: [March 24, 2022, 12:09pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/3 "2022-03-24T12:09:43Z")
A vote for `_S.sssssssss` to define the sub-second part down to nanosecond precision.
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [March 24, 2022, 12:15pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/4 "2022-03-24T12:15:44Z")
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.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [March 24, 2022, 12:21pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/5 "2022-03-24T12:21:24Z")
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
---
### Author:  [@tbeason](https://discourse.julialang.org/u/tbeason)
#### Post date: [March 24, 2022, 12:30pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/6 "2022-03-24T12:30:08Z")
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""`
---
### Author:  [@lawless-m](https://discourse.julialang.org/u/lawless-m)
#### Post date: [March 24, 2022, 12:36pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/7 "2022-03-24T12:36:31Z")
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
> [@Parsing of mysql timestamps](https://discourse.julialang.org/t/parsing-of-mysql-timestamps/77587/4):
>
> Thanks for the replies. I thought that Dataframes did’nt cast types as well it is probaly the DBInterface. This is the full stacktrace. The columnames are obfuscated and replaced by :Columns. [1] error(s::String) @ Base .\error.jl:33 [2] casterror(T::Type, ptr::Ptr{UInt8}, len::UInt32) @ MySQL C:\Users\lheinz\.julia\packages\MySQL\0vHyV\src\execute.jl:53 [3] cast(#unused#::Type{DateTime}, ptr::Ptr{UInt8}, len::UInt32) @ MySQL C:\Users\lheinz\.julia\packages\MySQL\0vHyV\s…
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [March 24, 2022, 1:19pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/8 "2022-03-24T13:19:59Z")
* * *
_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?
* * *
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [April 18, 2022, 6:54pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/9 "2022-04-18T18:54:21Z")
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?
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [April 18, 2022, 7:17pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/10 "2022-04-18T19:17:51Z")
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)
---
### Author:  [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)
#### Post date: [April 18, 2022, 8:48pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/11 "2022-04-18T20:48:30Z")
`NanoDates (NanoDate)` looks good.
`NanoTimes (NanoTime)` would also be easy to remember.
---
### Author:  [@Jordan\_Cluts](https://discourse.julialang.org/u/Jordan_Cluts)
#### Post date: [April 19, 2022, 2:52pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/12 "2022-04-19T14:52:49Z")
I agree that `NanoDates (NanoDate)` is really good. It’s very distinct from other date/time packages, descriptive, _and_ short.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [April 19, 2022, 3:25pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/13 "2022-04-19T15:25:24Z")
Great thanks @rafael.guerra @Jordan_Cluts
---
### Author:  [@lawless-m](https://discourse.julialang.org/u/lawless-m)
#### Post date: [April 20, 2022, 10:59am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/14 "2022-04-20T10:59:40Z")
I too thought `NanoDates` before I even saw your list of suggestions
we use nano-particles in regular speech rather than particle-nanos
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [April 20, 2022, 2:16pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/15 "2022-04-20T14:16:38Z")
🙂
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 2, 2022, 11:15pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/16 "2022-05-02T23:15:34Z")
never mind – revisiting
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 3, 2022, 8:16am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/17 "2022-05-03T08:16:38Z")
I am ready for some feedback.
The repo is [NanoDates.jl](https://github.com/JeffreySarnoff/NanoDates.jl)
There are some docs linked in the README.
To give it a whirl,
`add https://github.com/JeffreySarnoff/NanoDates.jl#main`
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 3, 2022, 8:30am UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/18 "2022-05-03T08:30:40Z")
Not yet documented is:
```julia
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
```
---
### Author:  [@Jordan\_Cluts](https://discourse.julialang.org/u/Jordan_Cluts)
#### Post date: [May 3, 2022, 4:00pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/19 "2022-05-03T16:00:45Z")
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`](https://docs.julialang.org/en/v1/stdlib/Dates/#Dates.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.
---
### Author:  [@JeffreySarnoff](https://discourse.julialang.org/u/JeffreySarnoff)
#### Post date: [May 3, 2022, 5:20pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/20 "2022-05-03T17:20:17Z")
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)
```julia
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"
```
---
### Author:  [@rafael.guerra](https://discourse.julialang.org/u/rafael.guerra)
#### Post date: [May 3, 2022, 5:40pm UTC](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377/21 "2022-05-03T17:40:00Z")
> [@JeffreySarnoff](#):
>
> `nd_nanosecs = NanoDate(2022,5,3,12,15,30,123,456,789)`
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:
```julia
nd_nanosecs = NanoDate(2022,5,3, 12,15,30, 0.123456789)
```
Thank you.
[Next page](https://discourse.julialang.org/t/timesdates-jl-dev-for-v2/78377.md?page=2)