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

[Łukasz Rekucki]

On 2 August 2015 at 21:19, Guido van Rossum <guido at python.org> wrote:
> On Sun, Aug 2, 2015 at 8:52 PM, Ethan Furman <ethan at stoneleaf.us> wrote:
>>
>> On 08/02/2015 10:32 AM, Łukasz Rekucki wrote:
>>
>>> I don't have much time to respond now, but please don't add leap seconds.
>>> People
>>>  are actively working to get rid of them entirely and they are never
>>> useful on the
>>> business level which this module is aimed at.
>>
>>
>> I don't know whether we should add support for leap-seconds to the new
>> strict tzinfo, but I will mention that the proposal to get rid of them keeps
>> being postponed, and leap seconds are actively harming the business
>> community precisely because they are not being accounted for.
>
>
> 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.)
>


But if we don't write a one, how do we know it's possible to do? IMHO,
the same approach was taken for tzinfo and DST and it didn't work out
very well.

For example, I probably could implement a timezone which represents
TAI (assuming I have always up-to-date leap seconds table), but it is
not possible because tzinfo.utcoffset() requires me to return an
integer number of minutes.

Most times you need leap seconds, is to ignore them (as Tim described
in his trading stock example). Adding support to a single programming
language and fixing it every application, won't make the world better.
Instead, you can use UTC-SLS or do what Google did.

[1]: http://www.cl.cam.ac.uk/~mgk25/time/utc-sls/


-- 
Łukasz Rekucki