On 2 August 2015 at 21:19, Guido van Rossum <[email protected]> wrote: > On Sun, Aug 2, 2015 at 8:52 PM, Ethan Furman <[email protected]> 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 _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
