You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a ZonedDateTime with a zero millisecond component is represented as a string, then the millisecond component is not shown in the String leading to parse errors if the String is parsed, e.g.:
julia> x=ZonedDateTime("2024-09-03T18:42:59.000+00:00")
2024-09-03T18:42:59+00:00
julia> parse(ZonedDateTime, string(x))
ERROR: ArgumentError: Unable to parse date time. Expected directive Delim(.) at char 20
Stacktrace:
[1] macro expansion
@ /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:104 [inlined]
[2] tryparsenext_core(str::String, pos::Int64, len::Int64, df::DateFormat{Symbol("yyyy-mm-ddTHH:MM:SS.ssszzz"), Tuple{…}}, raise::Bool)
@ Dates /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:38
[3] macro expansion
@ /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:150 [inlined]
[4] tryparsenext_internal
@ /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:125 [inlined]
[5] parse(::Type{ZonedDateTime}, str::String, df::DateFormat{Symbol("yyyy-mm-ddTHH:MM:SS.ssszzz"), Tuple{…}})
@ Dates /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:284
[6] parse(::Type{ZonedDateTime}, str::String)
@ Dates /snap/julia/104/share/julia/stdlib/v1.10/Dates/src/parse.jl:282
[7] top-level scope
@ REPL[228]:1
Some type information was truncated. Use `show(err)` to see complete types.
julia>
As far as I can tell, DateTime from the Dates standard library is always able to parse its own output and in my opinion, it would be nice if ZonedDateTime could do this as well.
The text was updated successfully, but these errors were encountered:
GHTaarn
changed the title
Missing milliseconds in string representation of ZonedDateTime
Enable ZonedDateTime to parse its own string representation
Sep 5, 2024
As far as I can tell, DateTime from the Dates standard library is always able to parse its own output and in my opinion, it would be nice if ZonedDateTime could do this as well.
I agree with this sentiment. TimeZones.jl uses Dates.jl for the underlying parsing engine and this will need to be addressed there to handle optional milliseconds with additional info after.
When a
ZonedDateTime
with a zero millisecond component is represented as a string, then the millisecond component is not shown in theString
leading toparse
errors if theString
is parsed, e.g.:As far as I can tell,
DateTime
from theDates
standard library is always able to parse its own output and in my opinion, it would be nice ifZonedDateTime
could do this as well.The text was updated successfully, but these errors were encountered: