Dates/TimeZones clash when decoding string date with terminal Z

General Usage
1

Dates.DateTime() can decode string dates with a terminal Z (for UTC). However, if TimeZones has been loaded, it fails, even using the module name (Dates.DateTime()).

What’s the best way of dealing with this?

julia> using Dates

julia> Dates.DateTime("2024-11-23T15:32:14.211Z", "yyyy-mm-ddTHH:MM:SS.sssZ")
2024-11-23T15:32:14.211

julia> using TimeZones

julia> Dates.DateTime("2024-11-23T15:32:14.211Z", "yyyy-mm-ddTHH:MM:SS.sssZ")
ERROR: ArgumentError: Unable to parse date time. Expected directive DatePart(Z) at char 24
2

A few different things are going on here:

There is no character code Z in the stdlib Dates per the Julia documentation. So, you’re matching a literal Z in your first example. It’s parsed like any of the delimiters.

TimeZones.jl overloads the Dates.jl functions with additional methods that accept Z or z as the character codes for time zones. So, it doesn’t matter if you prefix the functions with Dates..

TimeZones.jl uses the IANA database that doesn’t have a zone called Z. See the valid names with TimeZones.timezone_abbrs() or here.

I know, Z is often used to indicate UTC but it’s not in the official database. I usually just cut the Z off or replace it:

julia> DateTime(chopsuffix("2024-11-23T15:32:14.211Z", "Z"), dateformat"yyyy-mm-ddTHH:MM:SS.sssZ")

julia> DateTime(replace("2024-11-23T15:32:14.211Z", "Z"=>"+0000"), dateformat"yyyy-mm-ddTHH:MM:SS.ssszzzz")

Note the use of the dateformat"" macro instead of passing a plain format string. The latter is pretty expensive if you do that often.