[Python-Dev] Status on PEP-431 Timezones

[Isaac Schwabacher]

On 15-04-15, Lennart Regebro  wrote:
> On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher
> <ischwabacher at wisc.edu> wrote:
> > I am on the fence about EPOCH + offset as an internal representation. On the one hand, it is conceptually cleaner than the horrible byte-packing that exists today, but on the other hand, it has implications for future implementations of leap-second-awareness. For instance, offset measures the difference between the local time and UTC. But is it honest-to-goodness leap-second aware UTC, or is it really Unix time? This could be solved by giving each tzinfo a pointer to the UTC from which it is offset, but that sounds like a can of worms we don't want to open. But if don't and we store EPOCH + offset, we can't add leap second awareness to UTC without corrupting all persisted aware datetimes.
> 
> 
> That's true, with separate values like there is now we can easily
> allow 23:59:60 as a timestamp during leap seconds. I'm not entirely
> sure it makes a big difference though, I don't think we ever wants to
> deal with leap seconds by default.
> 
> I don't think we ever want the standard arithmetic deal with leap
> seconds anyway.
> 
> datetime(2012, 6, 30, 23, 30) + timedelta(seconds=3600) returning
> datetime(2012, 7, 1, 0, 29, 59)
> 
> 
> I guess leap second implementations should rather have special
> functions for arithmethics that deal with this.

You need relative timedeltas to mitigate the pain of leap seconds, yes. But as soon as you have timedeltas that are capable of representing "this number of seconds into the next minute" ("one minute") as opposed to "sixty seconds", this isn't so much of a problem. Though of course subtraction will (and should!) continue to yield timedelta(seconds=3601).

>From my perspective, the issue is more that the stdlib shouldn't rule out leap seconds. It's reasonable enough to expect users who actually want them to write appropriate tzinfo and timedelta classes, but we don't want to make that impossible the way the old tzinfo interface made DST-aware time zones impossible by insisting that implementers implement a function that wasn't mathematically a function.

I need to think about this more before I can get a real rant going.

ijs