[LEAPSECS] Lets get REAL about time.

[Stephen Colebourne]

On 27 January 2012 00:42, Hal Murray <hmurray at megapathdsl.net> wrote:

> I think the key idea is that there are several units of time and things like

> leap seconds, time zones, and leap years make conversion between them far

> from simple.

>

> We want to work with time in units of:

>  SI seconds

>  Days

>  Years

>  kilo- and mega- years

>

> Picking an API that focuses on one makes it hard to do things in the others.


Agreed, but I'd note that you missed out 1/86400th of a day. Many
developers will write code that does simple maths on a seconds count.
They do this because of developer mentality (too simple to use a
library, too slow to use a library, NIH...). If that kind of developer
is given only SI seconds, they will actually make more errors than if
they are given 1/86400th-econds.

I understand that the above paragraph really frustrates the experts,
time-nuts and scientists. But I strongly believe that it is
representative of what the human developers are doing and will do.
86400 per day and simple maths are *very* ingrained.

Thats why I still think that the SI-second should be renamed
(scientists and experts can handle that), leaving the second as a
number which divides the day into 86400 parts (probably with some
being rubber, and others not rubber).


> There are also months, but they are sufficiently non-uniform that nobody

> expects simple arithmetic conversions to work.


Interestingly, in JSR-310 I may end up representing a date as a packed
form of day-of-month (5 bits) and epoch-months (59 bits). Month
calculations are then easy.


> If we are going to make any progress in this area, I think we have to come up

> a collection of APIs that cover all the needs and a good description of how

> to decide which one to use, and why.


There are undoubtably multiple levels to the APIs needed. JSR-310 has
levels too. PHK is currently proposing the lowest level, a TAI seconds
clock. I think that is valuable, but I fear that only supplying the
conversion to struct tm is insufficient for the rest of the needs, and
will lead to abuse of the new API and probably more bugs than today.

Stephen