# [Datetime-SIG] Calendar vs timespan calculations...

Tim Peters tim.peters at gmail.com
Tue Aug 4 06:10:39 CEST 2015

```Sorry about this.  I don't want to talk about leap seconds anymore,
but I left a bad impression that intersects with what we _are_ doing.

[Guido]
>>> ...
>>> I like the idea of using a special tzinfo to reveal the leap seconds for
>>> those who really want them. (And we won't have to provide such a tzinfo --
>>> it's enough that one could be written, given a table of leap seconds.)

[Łukasz Rekucki]
>> But if we don't write a one, how do we know it's possible to do?

[Tim]
> Because it's a shallow problem:  not difficult, just tedious.

I should expound on _how_ tedious ;-)

The basic template for doing timeline arithmetic is:

1. Convert the datetime(s) to UTC.
2. Do straightforward classic arithmetic in UTC.
3. Convert back to original timezone (except for datetime-datetime
subtraction, in which case we're done).

This works because, in step #2, classic arithmetic is the same as
timeline arithmetic.  However, that relies on that Python's current
implementation of UTC ignores leap seconds. The approximated UTC is an
instance of "naive time".

But in a world with UTC leap seconds, that's no longer true.  In that
world, UTC doesn't match naive time, and classic arithmetic can't
work.  More is needed then, to move to another kind of time
bijectively related to UTC that _does_ match naive time (so that
classic arithmetic is correct).  Since real-life UTC is defined as an
offset (well, a collection of pattern-less offsets) from TAI, and TAI
is an instance of naive time, that's the obvious choice.  So add:

1.5.  Use the frickin' leap second table to convert to TAI.

and, in 2, s/UTC/TAI/, and

2.5  Use the frickin' leap second table to convert back to UTC.
```