I think you are mixing up a few things here, or I'm just misunderstanding you, which is just as possible (date/time is full of wonders, so no surprise there :-))
If you have a local date/time value which references a day and an time on that day, you can convert this into UTC without caring about leap seconds at all. The reason is that the conversion is done to, again, a date and a time on that day. The problems with leap seconds only matter when you care about time differences and then only if you need the elapsed time calculated in seconds when spanning multiple days. Most business applications only care about time differences calculated in number of days, or seconds between two times on a single day. In finance, you often even ignore complete days for the sake of simplicity (years having 360 days, all months having 30 days, etc. - there's a whole bunch of different systems to choose from). The few times where you really want to know the number of elapsed SI seconds between two points in time, you will most likely not use date/time objects for the calculation anyway, but instead revert to floats or integers counting nano seconds. For those cases, I think it's perfectly fine to have a package on PyPI which deals with the conversion from the point time to the value you are dealing with in your calculations and back again, so complicating the stdlib for this doesn't appear to me to be a good idea. BTW: In mxDateTime I have long resisted adding TZ code. The only TZ support currently in the system is for doing the one time conversion to UTC and back to local time again for display to the user when requested. IMHO, times should always be stored in "UTC", since that's the only half sane time standard that's understood by enough people to get decent interoperable work done (+/- 36 seconds that is, depending on who you talk to ;-)). Regarding terms: I started with "GMT" in mxDateTime, then added "UTC" as alias, and may well add "TAI" at some point as another alias. For most people, these are all the same, anyway :-) Purists will loudly disagree, of course, but I have the Zen of Python to my rescue: practicality beats purity. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 05 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> mxODBC Plone/Zope Database Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::::: Try our mxODBC.Connect Python Database Interface for free ! :::::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ _______________________________________________ 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/
