In every use-case that I've ever had, and every one that I can
imagine, I've not cared about the difference between "US/Eastern" and
"America/New_York". In fact, if ZoneInfo("US/Eastern") returned
something that had a name of "America/New_York", I would be fine with
that. Similarly, Australia/Melbourne and Australia/Sydney are, to my
knowledge, equivalent. (If I'm wrong on my own country's history of
timezones, then I apologize and withdraw the example, but I'm talking
about cases where you absolutely cannot tell the difference based on
the displayed time.) Having those compare equal would be convenient.
I tend to agree, but there's a minor complication in that there
is not, as far as I can tell, an easy cross-platform way to
determine the "canonical" zone name, and normalizing
America/New_York to the deprecated US/Eastern would be bad, so we
really don't want to do that (in fact, this happens with the way
that dateutil.zoneinfo stores its time zones, and has been rather
irksome to me). The key is exposed as part of the public API,
because it's useful for serializing the zone between languages,
e.g. if you want to send an aware datetime as JSON, you probably
want something that looks something like: {"datetime":
"2020-05-01T03:04:01", "zone": "America/New_York"}.
One reason this may be a problem is that something like
Asia/Vientiane is, at the moment, a symlink to Asia/Bangkok, but
Vientiane is in Laos and Bangkok is in Thailand - if time in Laos
changes relative to Asia/Bangkok, Asia/Vientiane will stop being a
link, but if we normalize "Asia/Vientiane" to "Asia/Bangkok" on
systems with sufficiently old time zone data, we may lose that
information on deserialization.
Of course, I do not consider this to be a major problem (any more
than the whole idea of stable keys over time is a somewhat fragile
abstraction), because if, for example, Massachusetts were to go to
"permanent daylight saving time" (i.e. year-round Atlantic
Standard Time), a new America/Boston zone would be created, and
all the Bostonians who have been using America/New_York would be
in much the same situation, but it's just one thing that gives me
pause about efforts to normalize links.
I don't think it's a problem to have equivalent objects unable to
coexist in a set. That's just the way sets work - len({5, 5.0}) is 1,
not 2.
I mostly agree with this, it's just that I don't have a good idea
why you'd want to put a time zone in a set in the first place, and
the notion of equivalent is relative to what you're using the
object for. In some ways two zones are not equivalent unless they
are the same object, e.g.:
dt0 = datetime(2020, 4, 1, tzinfo=zi1)
dt1 = datetime(2020, 1, 1, tzinfo=zi0)
dt1 - dt0
If we assume that zi0 and zi1 both are "America/New_York" zones,
the result depends on whether or not they are the same object. If
both zi0 and zi1 are ZoneInfo("America/New_York"), then the result
is one thing, if one or more of them was constructed with
ZoneInfo.no_cache("America/New_York"), it's a different one. The
result of `.tzname()`, `.utcoffset()` and `.dst()` calls are the
same no matter what, though.
Since options 3 and 4 are the most expensive, I'm fine with the idea
of a future method that would test for equivalence, rather than having
them actually compare equal; but I'd also be fine with having
ZoneInfo("US/Eastern") actually return the same object that
ZoneInfo("America/New_York") returns. For the equality comparison, I
would be happy with proposal 2.
Do you have any actual use cases for the equality comparison? I
think proposal 2 is reasonable, but to the extent that
anyone ever notices the difference between proposal 1 and proposal
2, it's more likely to cause confusion - you can always do
`zi0.key == zi1.key`, but most people will naively look at `zi0 ==
zi1` to debug their issue, only to not realize that `zi0 == zi1`
isn't actually the relevant comparison when talking about
inter-zone vs. same-zone comparisons.
ChrisA _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/JPUGSSXX2MWF3ABH3QNHXSMNVDWMRVJS/ Code of Conduct: http://python.org/psf/codeofconduct/