Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: DateTime of Dates module accepting microseconds too. #34175

Closed
hurak opened this issue Dec 21, 2019 · 2 comments
Closed

Feature request: DateTime of Dates module accepting microseconds too. #34175

hurak opened this issue Dec 21, 2019 · 2 comments

Comments

@hurak
Copy link

hurak commented Dec 21, 2019

Currently Julia supports only millisecond resolution through its Datetime type (in the standard Dates package). That is, it can accept date and time in the format

julia> df = DateFormat("Y-m-d H:M:S.s")
dateformat"Y-m-d H:M:S.s"

where the s after the decimal dot is only allowed to have up to three figures. In order words, there must be an integer number of millisecond.

A working example is below

julia> DateTime("2019-12-06 12:01:40.301",df)
2019-12-06T12:01:40.301

But another example below does not work

julia> DateTime("2019-12-06 12:01:40.301199",df)
ERROR: InexactError: convert(Dates.Decimal3, 301199)
Stacktrace:
 [1] tryparsenext at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/io.jl:153 [inlined]
 [2] tryparsenext at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/io.jl:41 [inlined]
 [3] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/parse.jl:64 [inlined]
 [4] tryparsenext_core(::String, ::Int64, ::Int64, ::DateFormat{Symbol("Y-m-d H:M:S.s"),Tuple{Dates.DatePart{'Y'},Dates.Delim{Char,1},Dates.DatePart{'m'},Dates.Delim{Char,1},Dates.DatePart{'d'},Dates.Delim{Char,1},Dates.DatePart{'H'},Dates.Delim{Char,1},Dates.DatePart{'M'},Dates.Delim{Char,1},Dates.DatePart{'S'},Dates.Delim{Char,1},Dates.DatePart{'s'}}}, ::Bool) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/parse.jl:40
 [5] macro expansion at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/parse.jl:150 [inlined]
 [6] tryparsenext_internal at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/parse.jl:127 [inlined]
 [7] parse(::Type{DateTime}, ::String, ::DateFormat{Symbol("Y-m-d H:M:S.s"),Tuple{Dates.DatePart{'Y'},Dates.Delim{Char,1},Dates.DatePart{'m'},Dates.Delim{Char,1},Dates.DatePart{'d'},Dates.Delim{Char,1},Dates.DatePart{'H'},Dates.Delim{Char,1},Dates.DatePart{'M'},Dates.Delim{Char,1},Dates.DatePart{'S'},Dates.Delim{Char,1},Dates.DatePart{'s'}}}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/parse.jl:282
 [8] DateTime(::String, ::DateFormat{Symbol("Y-m-d H:M:S.s"),Tuple{Dates.DatePart{'Y'},Dates.Delim{Char,1},Dates.DatePart{'m'},Dates.Delim{Char,1},Dates.DatePart{'d'},Dates.Delim{Char,1},Dates.DatePart{'H'},Dates.Delim{Char,1},Dates.DatePart{'M'},Dates.Delim{Char,1},Dates.DatePart{'S'},Dates.Delim{Char,1},Dates.DatePart{'s'}}}) at /buildworker/worker/package_linux64/build/usr/share/julia/stdlib/v1.3/Dates/src/io.jl:482
 [9] top-level scope at none:0

Obviously, microseconds are not allowed in DateTime type.

Although the Time type defined in the same built-in Dates package does allow for microseconds and even nanoseconds, constructing Time type variable by calling Time on DateTime is limited in the same way.

And yet allowing microseconds might be useful on some occasions (time from a GNSS receiver, for example). Furthermore, in Python their built-in datetime module does allow for microseconds in their datetime and time objects; interestingly enough, it only stores the subsecond time in (integer) microseconds.

I am willing to prepare a PR, but first I wanted to ask what is the general viewpoint. Is there a chance that such an extension of Julia's DateTime and Time types could be accepted? I think it can be prepared such that it does not break an older code. But I am asking first because maybe there was already some discussion of this and the current state of things is a result of a decision supported by some arguments.

@vtjnash
Copy link
Sponsor Member

vtjnash commented Dec 21, 2019

Agreed—duplicate of #31525.

@hurak
Copy link
Author

hurak commented Dec 21, 2019

Indeed, it appears the issues has already been discussed also on discourse. Sorry I did not check (carefully enough). Still, this way the need was voiced one more time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants