On Wed, Mar 10, 2004 at 09:59:32AM -0500, Dan Sugalski wrote:
: That means we can't convert to TAI, since that needs leap second info
: we don't have, so base time can't be TAI.
That part is only half true. Or maybe less than half, if UTC decides
to cut loose from astronomical time and ends up tracking TAI exactly
from now on. But we *do* know the mappings in the past. (Well,
for the recent past, anyway. :-)
: Right now, you can get a black-box integer timestamp that's fixed to
: GMT time, and you can disassemble that timestamp into day/month/year
: pieces. I adjusted the year to be a real year, but I haven't adjusted
: the month. We can do that, though. We can easily:
:
: *) Give a float timestamp
That would seem like good future proofing. Someday every computer will
have decentish subsecond timing. I hope to see it in my lifetime...
: *) Adjust the timestamp to various base dates (I've already made my
: preferences clear :)
0 on 1/1/2000 works out very well if it turns out we don't do UTC
leaps seconds any more. Then TAI and UTC only go nonlinear before
2000, and so far that's in the past, which is generally easier to
predict afterwards, given enough historical evidence.
And if they do add leaps to UTC in the future, then at least TAI
and GMT always march in lockstep, and we'll be no worse off than we
are now. :-)
"It will be very good if the fate of leap seconds is decided well
before POSIX has to consider how to store time after that date
in 2038." --http://www.ucolick.org/~sla/leapsecs/onlinebib.html
My guess is that eventually they'll decide to put a moratorium on
leap seconds, with the recommendation that the problem be revisited
just before 2100, on the assumption that we'll add all of a century's
leap seconds at once at the end of each century. That would let
civil time drift by at most a minute or two before being hauled
back to astronomical time. More to the point, it would put the
problem off till another day (not to mention another generation).
So that's my prediction. But then, I'm terrible at time estimation...
: *) Is what we're providing correct
I'd say what's missing are the error bars. I don't mind if the
timestamp comes back integral on machines that can't support subsecond
timing, but I darn well better *know* that I can't sleep(.25), or
strange things are gonna happen.
: *) What *aren't* we providing that we must to allow full and
: proper date processing in modules without much pain?
Snap-to-grid semantics for when the clock inevitably gets off by a
second or two from somebody's idea of the correct time. (But that
should be solved in your levels two through five, not in the
timestamp.) The basic idea is I can add 86400 seconds to yesterday
and I get the same time today, even if there was a leap second.
One would have to request such a "snap" explicitly, I expect, because
you'd have to communicate to it that you don't actually care about
sub-minute times, or whatever your "grid" specifies. But that's how
graphics programmers solve the mouse jitter problem, and I think we
can learn from them.
Larry
