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" <> wrote:
On Sat, Jun 30, 2012 at 12:29 PM, Guido van Rossum <> 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.