[Datetime-SIG] how does PEP-495 help improve dateutil, pytz timezone packages?

Akira Li 4kir4.1i at gmail.com
Wed Aug 26 05:35:12 CEST 2015

Alexander Belopolsky <alexander.belopolsky at gmail.com> writes:

>> On Aug 25, 2015, at 9:20 PM, Akira Li <4kir4.1i at gmail.com> wrote:
>> The code [4] can't be fixed without data from the tz database.
> .. or a working tm_zone/tm_gmtoff extension. Ok, I'll give you that
> even thought I thought we had some good enough work-around at least
> for the offset part.
> What does this all have to do with PEP 495?  If you are just saying
> that it does not solve all problems related to dealing with time zones
> in Python - I will be first to agree with you.  It solves only one
> problem: it enables tzinfo providers to achieve lossless conversion
> between time zones with varying utcoffset.  That's all.

I've described _in detail_ [1] what the connection between the
datetime.astimezone() failure and PEP-495 is. 

Here are some takeaways:

- History shows that the current datetime API is at least partially
  responsible [for] that the only working solution (pytz) has more
  complicated [then necessary] API. *It works but it might have been
  simpler and less error-prone*

- The important part is that PEP-495 should not make it even more
  difficult to use the packages [pytz, dateutil] correctly

- Ideally, PEP-495 should evolve with the corresponding experimental
  implementations [of the packages] that adapt the new flag.

> If you are saying that PEP 495 is not needed if all your time zones
> have fixed utcoffset - again no disagreement here.
> If you say that lossless conversion between varying utcoffset
> timezones should not be supported at all - I think you will find
> yourself in a small minority.

I don't understand what you mean but If we are choosing minorities then
I'm in this one [2]:

  This database (often called zoneinfo or tz) is used by several
  implementations, including the GNU C Library (used in GNU/Linux),
  Android, Firefox OS, FreeBSD, NetBSD, OpenBSD, Cygwin, DJGPP, MINIX,
  webOS, AIX, BlackBerry 10, iOS, Microsoft Windows, OpenVMS, Oracle
  Database, Oracle Solaris, and OS X.

Do you mean "varying utcoffset timezones" like dateutil's tzinfo object?
I've explicitly mentioned dateutil in "What are examples of
timezone-related issues that PEP-495 could solve?" section [1].

It is one of those cases where it is very easy to support 98.9%. The
difference and the vast majority of the work is in 1.1%. Until the
PEP-495 disambiguation flag is fully integrated in pytz, dateutil; it is
hard to tell whether it is worth it or it is even harmful in the end.

It seems you use timezone to mean a tzinfo instance. When we are
discussing the implementation of packages that provide access to the tz
database, let's use the term _time zone_ as it is understood there [3,5]:

  Within the tz database, a time zone is any national region where local
  clocks have all agreed since 1970

The typical timezone id is AREA/LOCATION such as America/New_York.

It is worth keeping an eye on the necessary enhancements mentioned by
Tim Peters [6] and how they may interact with PEP-495.

[2] https://www.iana.org/time-zones/repository/tz-link.html 
[3] https://en.wikipedia.org/wiki/Tz_database 
[6] https://mail.python.org/pipermail/datetime-sig/2015-August/000411.html

More information about the Datetime-SIG mailing list