[Python-Dev] Status on PEP-431 Timezones
Lennart Regebro
regebro at gmail.com
Wed Apr 15 18:55:33 CEST 2015
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.
//Lennart
More information about the Python-Dev
mailing list