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/JPUGSSXX... Code of Conduct: http://python.org/psf/codeofconduct/