[LEAPSECS] Lets get REAL about time.
hmurray at megapathdsl.net
Thu Jan 26 19:42:08 EST 2012
> 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
We want to work with time in units of:
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,
These are my opinions, not necessarily my employer's. I hate spam.
More information about the LEAPSECS