Multiple distinct UTCs: `Dates.UTC()`, `TimeZone("UTC")`, `TimeZone("Z")`

[tpgillam]

The Dates stdlib defines struct UTC <: TimeZone end, and it doesn't play nicely with ZonedDateTime. I was surprised to find this, partly since TimeZones.jl re-exports the UTC symbol.

For example:

using TimeZones

UTC() == tz"UTC"  # false

ZonedDateTime(2020, 1, 1, tz"UTC")  # 2020-01-01T00:00:00+00:00

ZonedDateTime(2020, 1, 1, UTC())  # ERROR

Stack trace...

``` ERROR: MethodError: no method matching ZonedDateTime(::DateTime, ::UTC)

Closest candidates are:
ZonedDateTime(::DateTime, ::TimeZone, ::FixedTimeZone)
@ TimeZones ~/.julia/dev/TimeZones/src/types/zoneddatetime.jl:14
ZonedDateTime(::Union{Period, TimeZone}...)
@ TimeZones ~/.julia/dev/TimeZones/src/types/zoneddatetime.jl:136
ZonedDateTime(::Integer, ::TimeZone)
@ TimeZones none:0
...

Stacktrace:
[1] ZonedDateTime(y::Int64, m::Int64, d::Int64, h::Int64, mi::Int64, s::Int64, ms::Int64, tz::UTC)
@ TimeZones ~/.julia/dev/TimeZones/src/types/zoneddatetime.jl:121
[2] ZonedDateTime(y::Int64, m::Int64, d::Int64, tz::UTC)
@ TimeZones ./none:0
[3] top-level scope
@ REPL[33]:1```

Maybe it would be nice if tz"UTC" === UTC()? Primarily because, semantically, I think they are intended to be the same thing.

aside: from some poking in src/types/fixedtimezone.jl it seems that tz"Z" is given special treatment. It is also distinct from tz"UTC". But then the following is a little surprising to me:

julia> parse(ZonedDateTime, "2020-01-01T00:00:00.000+00:00").timezone
UTC

julia> parse(ZonedDateTime, "2020-01-01T00:00:00.000Z").timezone
Z (UTC+0)

((the latter is also nearly twice as fast due to optimisations for Z... but this is even more off-topic))
Not that we should necessarily follow the behaviour of other languages, but Python would parse both the strings above to tz-aware datetimes with the identical 'UTC' timezone. Perhaps more importantly, "Z" is not in the IANA database, and is just a notation in ISO8601 to mean UTC as far as I can tell?

Apart from being a bit tidier, rationalising the standard ways of defining "UTC" to give a zero-size struct could be good for performance -- especially if we went down the route of parameterising ZonedDateTime, we could then end up with e.g. sizeof(ZonedDateTime{UTC}) == sizeof(DateTime), which would be great!

[omus]

I think we should support UTC in TimeZones.jl but I'm doubtful we can make UTC === tz"UTC" but we should at least make them ==.

[ancapdev]

Hi, ran into this issue today. Can work around it, but was surprised. Are there any updates on the plans for UTC handling?

[omus]

The hold up here is that UTC is currently a singleton instance which is only ever used as a type in now. It may be good to change that type to be abstract instead. However, doing that means we maybe should have tz"UTC" isa UTC be true if we define UTC as abstract type UTC <: TimeZone end.

A change we could implement in TimeZones.jl alone would be to support the singleton instance UTC in this package and treat UTC() == tz"UTC". We'd also need to document why both of these exist. One unfortunate part of doing this is we would have now(UTC) isa DateTime and have now(UTC()) isa ZonedDateTime both be true.

[ancapdev]

One unfortunate part of doing this is we would have now(UTC) isa DateTime and have now(UTC()) isa ZonedDateTime both be true.

Good point, that's more subtle and confusing than would be ideal.

Is there a history to why the standard Dates library defines TimeZone whilst leaving it to external packages like TimeZones to really make use of it? There's a lack of cohesion here to something fairly core.

[omus]

The definition of the TimeZone abstract type in Dates.jl pre-dates Julia 0.4. Possibly the intent was to roll time zone support into Dates.jl but I'm not fully sure.

I'm curious what @quinnj things of removing the TimeZone type and possibly UTC from Dates.jl? It definitely would be a breaking change and may be something to consider for breaking Julia change.

[quinnj]

Yeah, the intent of the TimeZone abstract type was just to provide a common definition for a TimeZones.jl package to leverage itself, and UTC was the only Base-provided subtype. I think removing UTC would be too breaking as there is a lot of production code out there that does Dates.now(UTC) (I at least am aware of a lot of usages of it).