[LEAPSECS] Lets get REAL about time.

[Hal Murray]

> Indeed, but that is a different task from what I am trying to specify here.

> I'm only trying to do the API for dealing with present and past time and

> timeintervals past us, in a computationally efficient manner. 



> There's a lot of business programming for which days are far more  important

> than seconds, but in those cases (interest, book releases,  etc), it's very

> much local legal time that matters, not a continuous  timescale.  Correct

> and current daylight saving time transitions are  more important than leap

> seconds and milliseconds in those cases. 


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.

There are also months, but they are sufficiently non-uniform that nobody 
expects simple arithmetic conversions to work.

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.

-------------

It might be possible to use seconds to describe times in the future if you 
also carried along some sort of fuzziness range.  The idea is to be able to 
say: X seconds from now, but I only need it to the day so I don't care about 
leap seconds or DST.  (But that breaks when your country jumps across the 
international date line.)

It might help if routines like localtime and gmtime had another parameter to 
tell them the round-off granularity:  minute, hour, day, month, year, 
century...


-- 
These are my opinions, not necessarily my employer's.  I hate spam.