There's no reason why you need to use date time objects for such extreme use cases. --Guido van Rossum (sent from Android phone) On Jun 30, 2012 10:17 AM, "Alexander Belopolsky" < alexander.belopolsky@gmail.com> wrote:
On Sat, Jun 30, 2012 at 12:29 PM, Guido van Rossum <guido@python.org> wrote: ..
The roundtrip requirement is telling though -- they have no way to actually represent a leap second in the underlying clock (which is a POSIX timestamp).
This correct: POSIX gettimeofday() cannot produce accurate UTC time during the leap second, but this does not mean that a python program should not be able to keep UTC time as accurately as the underlying hardware allows. Systems synchronized with official time using NTP, get notifications about leap seconds up to a day in advance and can prepare for a second during which NTP time stops. (As far as I understand, few systems actually stop their clocks or roll them back on a leap seconds - most slow the clocks down in various incompatible ways.) For example, during the leap second a software clock can use clock_gettime() (or Python's new time.monotonic()) function to get actual time.
For better worse, legal time throughout the world is based on UTC and once every couple of years there is a second that has to be communicated as hh:mm:60. Today we are fortunate that it is inserted during the time when most of the world markets are closed, but next time we may see a lot of lawsuits between traders arguing over whose orders should have been filled first. While few systems report accurate UTC time during a leap second, there is no technological limitation that would prevent most systems from implementing it. One can even implement such UTC clock in python, but valid times produced by such clock cannot be stored in datetime objects.