[time-nuts] Time math libraries

Tue Dec 13 00:34:54 UTC 2016

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 -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

-- 
Best regards,
 Timenut                            mailto:timenut at metachaos.net