I agree. It’s easier to add the right value comparison later than to take away over-engineering (also, YAGNI).
I particularly disagree with exposing all the transition data via eq. These should be opaque objects for most people, so at most the key is the identifier. Then you run into trouble with (not-)caching, but that’s the trouble with allowing people to bypass the cache, and I think we agreed that they just have to deal with extra complications? Object identity with the default/recommended usage gives the right result.
If we’re not doing value comparisons, then “equality by object” and “equality by key” are equivalent for people using the standard constructor, so the distinction between those two is really only meaningful for people bypassing the cache.
I think people bypassing the cache are hopefully more likely to understand that object identity matters (though this may not necessarily be true if they’ve inherited a framework that does this), but they may not have a good intuition about what “equality” means. I think people will make the reasonable assumption that “object equality means the results are always the same when using these two zones”, which is something we can only guarantee with object identity or equivalent-transitions, so I think that from that perspective, you run into less trouble with __eq__ being equivalent to a is b than if you go with __eq__ being equivalent to a.key == b.key (plus if you make a mistake about what it means, you’ll probably notice a whole lot more quickly this way).
My concern was about loading the same zone by two different means and get not identical objects (zone1 is not zone2) but equal transition data (what I wrote as “zone1 == zone2”).
The problem is that defining the equal operator opens a can of worms. For me, Europe/Paris and Europe/Brussels are the same because they have the same UTC offset today. But Europe has a long history, and France and Belgium didn’t always have the same time (I didn’t check, but I’m quite sure that these neighbors had different time a few days since 1900).
So yeah, I understand that a new “equivalent_transitions()” function or method should be designed to take in account what the user “expects”. It’s also ok to leave this problem out of the stdlib for now. For example, I can put such code in my application:
def same_utfoffset_now(zone1, zone2):
now = datetime.datetime.now()
return (zone1.utcoffset(now) == zone2.utcoffset(now))
Let’s start simple with the uncontroversial part and complete the API later
Not yet. I hope that the implementation will land before Python 3.9.0 beta1. Currently, the implementation lives at: https://github.com/pganssle/zoneinfo
Yes, this will be available before the beta. It’s nearly ready now, it mostly just needs documentation.
I’m also planning on re-using the reference implementation as a stand-alone backport installable from PyPI on Python 3.7+, which will likely be ready even before the first beta release.
Would you consider TZPATH as the environment variable name? The aim being to establish a convention that other tools/languages can adopt, perhaps one that’s eventually standardized. Or is that too much to pile on at once?
A search found one clashing use in the Tezos test suite, but it’s fairly obscure.
Would calling the module timezoneinfo be a nice middle ground? It clarifies the type of zone is in question (as opposed to DNS zones), and it helps to mentally group it with datetime, but on the downside it’s quite long.
We can always add that later if other language stacks want to standardize on it, but keeping it namespaced under PYTHON seems like a safer bet (particularly if other language stacks use a different convention, e.g. they don’t allow a full search path, or they do allow relative paths, etc).
