[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo
> 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-le...@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/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/JVNW32COCOLBAKPREUSW7Z3TGFOMTJIB/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo
> 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-le...@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/
signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/AW3ZMWX6MNDU35L3AW5RIRYF7MAYFCZW/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Further PEP 615 Discussion: Equality and hash of ZoneInfo
On Sun, Apr 19, 2020 at 3:39 AM Paul Ganssle wrote:
>
> A few weeks ago, I submitted PEP 615 to the steering council for a decision.
> There's been a decent amount of discussion there with some very good
> questions. I think they are mostly resolved (though I'm happy to have other
> people look over the logic of some of my responses there), but Victor brought
> up the question of the equality and hash behavior of ZoneInfo, and while I'm
> leaning one way, I could easily be convinced - particularly if people have
> real use cases that they are planning to implement that would be affected by
> this.
>
> I've summed up the options on the discourse thread, and would appreciate if
> anyone is able to give some feedback.
>
> Thanks!
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 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.
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.
ChrisA
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@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/
