Eric, I speak as someone who has implemented many calendrical packages. I have always tried to achieve the maximum degree of generality, and have considered the issues with leap seconds on more than one occassion.
The first problem with leap seconds is that you need a list of them, and that list needs constant updating. If date/times are maintained in a standard form such as seconds since the beginning of an epoch (e.g. 0 AD) then even the conversion into a conventional date/time is dependent upon the country you are in. That is just too much overkill for the usual purpose. In practice, a date/time is loaded from a file or obtained from an operating system (which MAY take leap seconds into account). At that point it is just a date/time to be manipulated. If you should be unlucky enough to get a date/time exactly in a leap second - it really doesn't matter because date/times are just not synchronized well enough for it to matter. Where it does matter, there is some local clock which is used and the date/times are relative to it. This is almost always for timestamps, and the time since the system boot will generally do well unless you need it across a network. Then even cable delays become a problem. So taking leap seconds into account requires a substantial amount of additional coding, constant updates of possibly distributed code to keep the list of leap seconds maintained and adversely affects both storage and performance. For practical matters, even if it could be done at zero cost, there is no real benefit. Just allowing a day to have 86,401 seconds causes all sorts of problems with data storage, consistency verification, editing and ensuring that data entry is correct. It is the rare application that needs leap seconds - even though it may be "correct", and certainly an option I have considered many times - but it has never been justified for anything that I have ever written (which actually includes operating systems). Consider that the system clock for any processor will "slip" on a regular basis and need to be reset. The accuracy that most operating systems can maintain in practice is, at best, only on the order of a second or two - and that is with regular updates from a timing source. Now, if you have a processor with a built-in GPSDO, perhaps that could be used to regulate the system clock (which is just a cheap quartz crystal) and keep time synchronized to perhaps a millisecond or so. Maybe. But, probably not. All that is left would be specialized applications that actually require leap seconds. I don't know of any, but there may be some available. Certainly an operating system could maintain the necessary lists (assuming that it is regularly updated). It could use that data for conversions. I don't know of an operating system that does that though because of the data format problems. They would report a time such as 24:00:00 which would otherwise be invalid. That specific time is usually taken as 00:00:00 of the next day. Very few, if any applications would understand 24:00:00 as a valid time. So, operating systems can't really afford to take leap seconds into account either. Michael > (Apologies if this question has been addressed before. Archive search is > rather cumbersome on a month-by-month basis.) > Few people will be surprised to learn that MS Excel does not account for > leap seconds when doing time math. See below for an example. This is just an > example of many instances of programming failures. > Are there good time math software libraries (e.g., Java, C++/C#, etc) > that will do time math correctly for the chosen time scale? > Thanks. > — Eric > 2016 Dec 31 Sat 23:59:57 > 2016 Dec 31 Sat 23:59:58 > 2016 Dec 31 Sat 23:59:59 > 2017 Jan 01 Sun 00:00:00 > 2017 Jan 01 Sun 00:00:01 > 2017 Jan 01 Sun 00:00:02 > My machine is on EST right now. Is it a time zone question? > 2016 Dec 31 Sat 18:59:57 > 2016 Dec 31 Sat 18:59:58 > 2016 Dec 31 Sat 18:59:59 > 2016 Dec 31 Sat 19:00:00 > 2016 Dec 31 Sat 19:00:01 > 2016 Dec 31 Sat 19:00:02 > Nope! > What about past leap seconds? > 2015 Jun 30 Tue 23:59:57 > 2015 Jun 30 Tue 23:59:58 > 2015 Jun 30 Tue 23:59:59 > 2015 Jul 01 Wed 00:00:00 > 2015 Jul 01 Wed 00:00:01 > 2015 Jul 01 Wed 00:00:02 > Also fail! > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts > and follow the instructions there. -- Best regards, Timenut mailto:[email protected] _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
