Dates and times again
Dan Sugalski
So far as I can see, we need, in descending order of importance (and
speed) (And if there's stuff missing, add them):
1) A timestamp value
2) A way to chop the timestamp to pieces
3) A way to turn the timestamp into a string
4) A way to turn pieces to a timestamp
5) A way to turn the string into a timestamp
All of which is confounded by the joys of timezones and platform limitations.
As far as I can tell, the only thing we can absolutely count on are:
asctime, ctime, difftime, gmtime, localtime, mktime, strftime
We can't even count on timegm, unfortunately. Neither can we count on
getting fractional time. (Or even really count on getting a GMT time
that's actually GMT, as far as that goes, but that's
user-misconfiguration and there's a limit to what I'm willing to care
about) Nor strptime for time parsing, though a case could be made
there that we could do our own. (Cases to be made for that should be
accompanied by unencumbered source to do the parsing ;) Can't even
count on the full range of output when splitting the time up--if you
check the CVS logs you'll see I yanked out a few elements because
they're not C89 and there wasn't any way to synthesize them easily
that I know of.
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. From what I can tell from
the interfaces and long painful experience we can't convert to and
from anything other than the current system timezone. (Maybe. I'm not
100% sure that's reliable either)
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
*) Adjust the timestamp to various base dates (I've already made my
preferences clear :)
My general rule-of-thumb for ops is that they must:
*) Be something we want to guarantee behaviour on everywhere
*) Require C code
*) Have a fixed signature
Being primitive isn't necessary as such, but doesn't hurt. Having to
be required present at all times isn't necessary either, though we
should nail down lexical oplibs if we want to start talking about
secondary libraries of this stuff.
Anyway, given the restrictions on what we have to work with, the
first question is:
*) Is what we're providing correct
*) What *aren't* we providing that we must to allow full and
proper date processing in modules without much pain?
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Larry Wall
: That means we can't convert to TAI, since that needs leap second info
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
Steve Allen
> 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.
The results of the Torino colloquium indicate that there will almost
certainly be leap seconds through the year 2022, for anything sooner than
that is too soon to make such a drastic change in time keeping. But if
earth rotation keeps accelerating much longer, it will become necessary
to have *negative* leap seconds. See the rotation plots at
http://www.ucolick.org/~sla/leapsecs/dutc.html
> My guess is that eventually they'll decide to put a moratorium on
> leap seconds
Be careful what you wish for. The results of the Torino colloquium are at
http://www.ien.it/luc/cesio/itu/ITU.shtml
In particular note the final results in sections 4 and 5 of
http://www.ien.it/luc/cesio/itu/annex_a.pdf
If leap seconds are abandoned, then UTC itself will be abandoned and
replaced by something with a new and different name. That means that
every agency, government, and standards document which references UTC
will presumably have to change to reflect whatever new time scale
is deemed most suitable.
Furthermore, if leap seconds are abandoned in the fashion indicated by the
colloquium, then for practical purposes TAI will also be abandoned.
There will be little point in referencing anything to the old TAI if
the radio broadcasts providing time to every modern system clock are
expressed in the newfangled TI.
So the demise of leap seconds would probably mean the demise of every
practical time scale now in use.
Nick Ing-Simmons
>In an attempt to drain the swamp...
>
>So far as I can see, we need, in descending order of importance (and
>speed) (And if there's stuff missing, add them):
>
>1) A timestamp value
>2) A way to chop the timestamp to pieces
>3) A way to turn the timestamp into a string
>4) A way to turn pieces to a timestamp
>5) A way to turn the string into a timestamp
>
>All of which is confounded by the joys of timezones and platform limitations.
>
>As far as I can tell, the only thing we can absolutely count on are:
>
> asctime, ctime, difftime, gmtime, localtime, mktime, strftime
Everything gives you a ticks of size ? since ? hook or three.
In most places the ticks are less than second.
All the stringify and human/planet-izing seems to be library fodder.
gettimeofday() is widely available or fakeable. (Tk uses it.)
Seems $^T could start based on time(2) and then get deltas using
something finer. Perhaps aspire to clock_gettime() and fake
that interface where not available?
Nick Ing-Simmons
>
>That would seem like good future proofing. Someday every computer will
>have decentish subsecond timing. I hope to see it in my lifetime...
It isn't having the sub-second time in the computer it is the API
to get at it...
>
>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.
Given that most people live more than an minute or two from their
civil-time meridian who will notice? (Says me about 8 minutes west of
GMT.)
>
>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.
But you can fake sleep() with select() or whatever.
Leopold Toetsch
> Larry Wall <la...@wall.org> writes:
>>..., but I darn well better *know* that I can't sleep(.25), or
>>strange things are gonna happen.
> But you can fake sleep() with select() or whatever.
$ cat sl.pasm
sleep 0.1
end
$ time parrot sl.pasm
real 0m0.116s
user 0m0.010s
sys 0m0.000s
leo