On Wed, Apr 15, 2015 at 12:40 PM, Isaac Schwabacher <ischwabac...@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 _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
