4 ms·

I’ve only read the top level part of the PEP, but it sounds like they’d rather keep the Python source code clean than reuse `datetime.timezone`. They optimised

I’ve only read the top level part of the PEP, but it sounds like they’d rather keep the Python source code clean than reuse `datetime.timezone`. They optimised for, what, 20 people instead of optimising for thousands. I am not impressed at all. “Optimising” here is quite a euphemism too. The omission of timezones from the standard library, alongside allowing timezone naive datetimes, has been a major implementation flaw for a long time.

lifthrasiir 4y ago
I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & time library in the past). One of such problems is to keep the database up to date, which is nothing but trivial. I'm very confident that the OS-level time zone data is the only database you can be reasonably sure that it's likely up to date, and different OSes expose (sometimes accidentally) different bits of data. Any other solutions are not very automated and tend to drift, I've seen systems where pytz or Java's TZUpdater neglected for a while. I hoped TZDIST [1] to be a thing, but it is not widespread enough, to say the least. In this sense PEP 615 is not exactly the solution but a stopgap; it essentially admits that we can't exactly solve this problem, but we can at least include the existing half-solution into the batteries. [1] https://www.rfc-editor.org/rfc/rfc7808.html https://www.rfc-editor.org/rfc/rfc7808.html
progval 4y ago
Reusing datetime.timezone would not make sense. datetime.timezone represents fixed UTC offsets, while ZoneInfo objects represent IANA timezones (which generally don't have a fixed offset).
- lifthrasiir 4y ago
  I believe GP wants something like `datetime.timezone.from_tzid("Etc/UTC")`, which is by itself a fine backward-compatible upgrade from the original interface.
  - Macha 4y ago
    I would disagree that this is a fine interface. It's not clear with the "Etc/UTC", but what is the offset of datetime.timezone.from_tzid("America/New_York")? You need a datetime to go with the TZ id to answer that question. And experience has shown "Just assume the current time" is a bit of a footgun.
    - lifthrasiir 4y ago
      As currently defined, datetime.timezone doesn't directly expose the zone offset as a whole and always requires some reference datetime object to compute it, even though the built-in implementation would simply ignore it for now [1]. So it can be surely upgraded. [1] https://docs.python.org/3/library/datetime.html#datetime.timezone.utcoffset https://docs.python.org/3/library/datetime.html#datetime.tim...

lifthrasiir 4y ago

I see where you come from, but a timezone database presents several challenging design problems to date and time libraries (I have written some popular date & time library in the past). One of such problems is to keep the database up to date, which is nothing but trivial. I'm very confident that the OS-level time zone data is the only database you can be reasonably sure that it's likely up to date, and different OSes expose (sometimes accidentally) different bits of data. Any other solutions are not very automated and tend to drift, I've seen systems where pytz or Java's TZUpdater neglected for a while. I hoped TZDIST [1] to be a thing, but it is not widespread enough, to say the least. In this sense PEP 615 is not exactly the solution but a stopgap; it essentially admits that we can't exactly solve this problem, but we can at least include the existing half-solution into the batteries. [1] https://www.rfc-editor.org/rfc/rfc7808.html https://www.rfc-editor.org/rfc/rfc7808.html

progval 4y ago

Reusing datetime.timezone would not make sense. datetime.timezone represents fixed UTC offsets, while ZoneInfo objects represent IANA timezones (which generally don't have a fixed offset).

lifthrasiir 4y ago
I believe GP wants something like `datetime.timezone.from_tzid("Etc/UTC")`, which is by itself a fine backward-compatible upgrade from the original interface.
- Macha 4y ago
  I would disagree that this is a fine interface. It's not clear with the "Etc/UTC", but what is the offset of datetime.timezone.from_tzid("America/New_York")? You need a datetime to go with the TZ id to answer that question. And experience has shown "Just assume the current time" is a bit of a footgun.
  - lifthrasiir 4y ago
    As currently defined, datetime.timezone doesn't directly expose the zone offset as a whole and always requires some reference datetime object to compute it, even though the built-in implementation would simply ignore it for now [1]. So it can be surely upgraded. [1] https://docs.python.org/3/library/datetime.html#datetime.timezone.utcoffset https://docs.python.org/3/library/datetime.html#datetime.tim...