Em Seg, 2010-02-22 às 13:31 -0500, Mark J. Reed escreveu:
> > I'd just like to add that Instant is not "more-or-less" opaque. It is
> > "entirely" opaque.
> Not according to S02, which says that an Instant will numify to the
> number of TAI seconds since "the TAI epoch". That's not opaque.
I'd just like to quote a bit from the same doc..
If pressed for a number, an Instant will return the length of
time in atomic seconds from the TAI epoch, but it will be
unhappy about it. [...] Systems which cannot provide a steady
time base, such as POSIX systems, will simply have to make their
best guess as to the correct atomic time.
> And since it apparently wasn't clear, all I'm asking for is what "the
> TAI epoch" is. Again, I *assume* it's January 1, 1958 at midnight
> UT2, at which point TAI was synchronized to have exactly that same
> value, but it's not stated as such in the spec, and there are other
> reasonable values (onset of UTC in 1972; switch to modern relativistic
> corrections to the measured SI seconds in 1977).
And my point is precisely that the spec doesn't define it because it is
implementation and architecture dependant.
The point is that you shouldn't use a number alone to represent an
instant, the coercion from instant to numeric is just a convenience,
and, in fact, could actually be removed since Instant can override most
math operators.
Note that not even the TAI coordination happens in terms of "number of
seconds since X", but rather happens in terms of Gregorian or Julian
dates.
This is the same mindset as why you can't see a Str as an array of bytes
without an explicit conversion (which requires an encoding).
The biggest difference proposed by the use of TAI is that when you ask
for the number of seconds between "2008-12-31T23:59:59+0000" and
"2009-01-01T00:00:00+0000" you'll get 2 because of the leap second. But
you don't need to know how many seconds there were in the TAI scale
since the 1958 epoch to find that out, you just need to know when we had
leap seconds.
> Two different problems. The TAI epoch is defined as a point on the
> TAI scale, and the number of TAI seconds since that point is always
> well-defined. When asking for epoch-based time, you're not starting
> with a Gregorian DateTime and trying to convert it.
The thing is, most operating systems would require extra conversions in
order to get there, when in most cases the need is:
a) Get the Duration of the difference from another instant obtained in
the same process...
b) Get the Duration of the difference from another DateTime (in a given
calendar, in a given time zone)
or
b) Get it as a Gregorian DateTime in some timezone (local or UTC)
That way, an implementation can keep it's Instant objects using time_t
(unless high-resolution time is requested) and convert directly to a
Gregorian DateTime without ever worrying about TAI seconds (in fact,
modern POSIX time_t *is* Gregorian::DateTime compatible without any
conversion)...
> But even if you did do such a conversion, as long as you assume that
> the input date is UTC, the conversion to TAI is well-defined, too.
> (And if you don't make that assumption, then you're opening a large
> can of worms; see
> e.g.http://www.ucolick.org/~sla/leapsecs/epochtime.html ).
Important point. I can't assume the input date is UTC, I can't even
assume it uses the gregorian calendar. So yes, we already openned that
large can of worms...
daniel
