Re: C1X calendar and long time proposals
- From: Michael Deckers <Michael.Deckers@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 21 Sep 2009 12:43:08 +0000
On 2009-09-20, David R Tribble wrote:
> Michael Deckers wrote:
> > I see. What I do not see is which longtime_t values can
> > distinguish the two different instants when UTC was
> > 2005-12-31T23:59:60 (with 32 leap seconds), and
> > 2006-01-01T00:00:00 (with with 33 leap seconds).
> > NTP timestamps have the leap second bit to distinguish
> > them -- but longtime_t values don't.
>
> Those two times differ by one second, so their corresponding
> longtime_t values differ by one second's worth of ticks, i.e., the
> later time will be 2^29 greater than the earlier time.
OK, this means that you do mean [b] after all: longtime_t values
are intended to represent
[b] floor( ( TAI - 2001-01-01 - 32 s )/( 2^-29 s ) ).
I probably should have stated that I meant the difference in both
formulae to be taken as in the POSIX formula for "seconds after the
epoch", without any leap second magic, so that the difference
2006-01-01T00:01:00 - 2005-12-31T23:59:00
is always 120 s, regardless of the time scale (TAI or UTC or TDB or..).
> Likewise, passing these values to longtimeleapsecs() will return
> 33 for both, as they both include the same (33rd) leap second.
> Passing a value representing one tick before the earlier
> time (i.e., the point in time prior to the insertion of the 33rd leap
> second) will return 32.
That's the question: when exactly does TAI - UTC increase by 1 s
upon insertion of a positive leap second. The leap second mentioned
above goes
from 2005-12-31T23:59:60 UTC until 2006-01-01T00:00:00 UTC and
from 2006-01-01T00:00:32 TAI until 2006-01-01T00:00:33 TAI.
In Ada05, the increase in TAI - UTC is taken to occur at the
beginning of the leap second, as you propose. But the time stamps
in Ada05 for the leap second above go
from 2005-12-31T23:59:59 until 2006-01-01T00:00:00
(Ada05 does not use out of range seconds fields), so that the
discontinuity in the calendar components is indeed at the beginning
of the leap second. With the UTC time stamps using overflowing
seconds fields, the discontinuity might be taken to occur at the
end of the leap second. However this is decided, it should be
documented because the official definition of UTC (["Recommendation
ITU-R TF.460-6 Standard-frequency and time-signal emissions".
2002 Geneva]) is silent on this point.
> As I've said before, I would just as soon ignore leap seconds,
> but more than one person in comp.std.c has made it clear
> that applications that need leap seconds really need them
> badly. All other applications can simply remove them, either
> using longtimeleapsecs(), or by ignoring cal_sec values
> greater than 59 when converted to calendar date objects.
> The cal_leapsecs member is also present for this need.
A proposal to cease the use of leap seconds in UTC is under discussion
since at least 2000 ([http://www.ucolick.org/~sla/leapsecs/]).
However, ITU standardization seems to be even slower than
programming language standardization by ISO, so that leap seconds
will probabaly still be with us when standard C1x is issued. And then,
dealing systematically with time scales that are non-injective functions
of TAI (such as UTC at positive leap seconds, and time zone times upon
their switch to winter time) is a nice and challenging design problem!
Michael Deckers.
.
- References:
- Re: C1X calendar and long time proposals
- From: David R Tribble
- Re: C1X calendar and long time proposals
- From: David R Tribble
- Re: C1X calendar and long time proposals
- From: Michael Deckers
- Re: C1X calendar and long time proposals
- From: David R Tribble
- Re: C1X calendar and long time proposals
- Prev by Date: Re: fscanf(), strtol() and the parsing of numbers
- Next by Date: Re: C1X calendar and long time proposals
- Previous by thread: Re: C1X calendar and long time proposals
- Next by thread: Re: C1X calendar and long time proposals
- Index(es):
Relevant Pages
|
Loading
