[Datetime-SIG] Fwd: Calendar vs timespan calculations...

Tim Peters tim.peters at gmail.com
Fri Aug 7 00:11:23 CEST 2015

[Chris Barker]
> Uhhm, but it seems I've been told over and over again in this thread that I
> shouldn't want leap seconds, no one cares about them, and python will never
> support them?!??!?

Nobody denies that you need accurate deltas in SI seconds, and nobody
suggests that you "shouldn't" need them.  But, kinda yes, almost
everyone will tell you that only a relative handful (not "no one") of
programmers and apps care about exact SI durations.

Over half the advice you've been given assumes you would like to solve
the problem you have sometime this decade ;-)  If you do, then the
simplest path to solving it _soon_ is to use TAI internally.  Get the
very _notion_ of leap seconds (and DST transitions, and
base-offset-from-UTC transitions) out of the representation you use
for computation, and then the arithmetic needed to work with exact SI
durations is simple, reliable, fast and surprise-free.

Not just in Python, but in any other language you care to use, and you
don't need any changes to any language or library to pursue this path.
You would need to write to/from TAI conversion functions yourself
(which, in Python, can build on .astimezone() to do the bulk of the
work), and maintain a leap seconds table yourself.  While not trivial,
neither is that a large project.

Or you could try using the astropy package, which I pointed at before,
which already implements TAI.  I believe it's included in all versions
of Enthought''s Scientific Python distribution, so I wouldn't be
surprised if you - as a scientist - already have it.  However, I never
used astropy, and don't, e.g., know whether it supports conversions
between astronomical and civil time schemes.

If you want to talk about the indefinite slobbering ;-) future instead:

> So can we just leave it at:
> "There are no plans for python to support leap seconds, and it is also not a
> motivating factor in current work to make it possible in the future."

I can't speak for everyone on this.  Guido already said he's not
interested, but Alexander is clearly paying attention to it anyway.

For me, it's just another kind of annoying time adjustment, no
different in principle from annoying DST adjustments, so I expect we
would have to go out of our way to _preclude_ someone implementing
leap second support some day.  However, I'm skeptical of that anyone
wants leap second support enough to do all the work required to
implement timeline arithmetic taking account of them.

> ...
> As long as it's a 26 or so seconds problem, I'm fine. On the other hand, we
> just got a data set encode to a "I have no idea why" epoch before 1970,
> which breaks all our old C code that uses unsigned integers since 1970. So
> we have to translate that to a better epoch first (using python's datetime,
> natch).

Users.  The best part of retirement is that I'm my only user now - and
I'm _still_ endlessly annoying to me ;-)

More information about the Datetime-SIG mailing list