`Expected directive DatePart(Z)` after importing TimeZones.jl

[AzamatB]

The following works fine:

julia> using Dates

julia> Dates.DateTime("2020-10-22T16:52:14.409Z", dateformat"yyyy-mm-dd\THH:MM:SS.sZ")
2020-10-22T16:52:14.409

Now if I add to it using or even import of TimeZones, then now the same code fails:

julia> using Dates

julia> import TimeZones

julia> Dates.DateTime("2020-10-22T16:52:14.409Z", dateformat"yyyy-mm-dd\THH:MM:SS.sZ")
ERROR: ArgumentError: Unable to parse date time. Expected directive DatePart(Z) at char 22
Stacktrace:
 [1] macro expansion at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/parse.jl:104 [inlined]
 [2] tryparsenext_core(::String, ::Int64, ::Int64, ::DateFormat{Symbol("yyyy-mm-dd\\THH:MM:SS.sZ"),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'},Dates.DatePart{'Z'}}}, ::Bool) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/parse.jl:38
 [3] macro expansion at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/parse.jl:150 [inlined]
 [4] tryparsenext_internal at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/parse.jl:125 [inlined]
 [5] parse(::Type{DateTime}, ::String, ::DateFormat{Symbol("yyyy-mm-dd\\THH:MM:SS.sZ"),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'},Dates.DatePart{'Z'}}}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/parse.jl:282
 [6] DateTime(::String, ::DateFormat{Symbol("yyyy-mm-dd\\THH:MM:SS.sZ"),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'},Dates.DatePart{'Z'}}}) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.5/Dates/src/io.jl:482
 [7] top-level scope at REPL[8]:1

[iamed2]

As a workaround, this should work in both scenarios:

Dates.DateTime("2020-10-22T16:52:14.409Z", dateformat"yyyy-mm-dd\THH:MM:SS.s\Z")

Escaping the Z in the format ensures it is always parsed as a literal Z.

[yalwan-iqvia]

#306 seems related (although stacktrace is different). Happy for #306 to be closed as a dupe of this if maintainer deems it so.

[omus]

I agree that this is a frustrating problem and not a great solution.

Unfortunately this has to do with the way Dates formatting was set up a while ago. @omus may be looking at an overhaul of that when he's back from leave.

Perhaps Base can change to recognize the Z with a fallback in order to make the case when TimeZones is loaded similar to the case where it isn't?

Or, with a major release, TimeZones could stop using the capital Z, which is a common literal character in timestamps.

I'm going to leave this up to @omus though as I'm not really a maintainer of this package.

Quoted from #306. There are a few things with the DateFormat syntax that need changing. However, as that will be a big undertaking we probably need a fix to make things work better for now.

I think the cleanest fix would be to reserve A-Z and a-z as character codes. If you attempt to use a reserved character code which doesn't have a defined behaviour (e.g. X) then you'd get an error telling you to either load the package which defines the behaviour for that character code first or escape the character. If you want to use a reserved character as a literal then you'd need to escape them.