[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 ;-) _______________________________________________ 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/
