Rob wrote:
Martin Burnicki <martin.burni...@meinberg.de> wrote:
The main problem is that the underlying system time (often POSIX, which
just counts seconds since an epoch) has the *same* time stamp art the
beginning and end of the leap second.
In order to do the conversion correctly you need to know if the current
second is the leap second, or not, i.e. you need some status flag in
addition to the raw (e.g. POSIX) timestamp.
This is basically similar to what you have at the end of DST, where (in
local time) a whole hour is passed twice. You need to know the DST
status to determine unambiguously if it's the first or the second turn.
Yes, but in situations where you care about that you store just the
system time, and the conversion to local time can be repeated later.
Thanks to the powerful conversion routines in glibc this can be done
even way in the past (because it remembers DST rules from previous years).
Agreed, for this case it works, due to effort of the tzdata maintainers.
Unfortunately, the same mechanism isn't used for leap seconds.
There would be no problem at all when the system time ticked in TAI
and the addition of the leap seconds is done via some rule table similar
to the local time rules. ntpd would not even be involved in the problem.
Also agreed. However, actually ntpd expects UTC, not TAI.
In spite of this it may eventually work if you set up an NTP server
where the system time runs on TAI and you use one of the "right" time
zones which are also part of the tzdata package. I haven't tried this.
You'd have to take care that ntpd does *not* announce leap seconds in
this case, but you'd have to update the leap second information anyway,
since otherwise the conversion done according to the "right" time zone
rules would be wrong. ;-)
A main reason for the problems with leap seconds is that POSIX has just
ignored them when they defined their standards on timekeeping.
That is the problem. And probably also the decision in Unix to count
UTC seconds since Jan 1st, 1970 (instead of TAI seconds).
Back then it did not matter that much in a timesharing system. The
system clock was mainly a convenience feature, not critical to anything.
(it usually had to be set on every boot and this was done by typing
the time seen on the operator's wristwatch, hence the term "wristwatch time")
Again agreed. Using TAI for sytem time and a current leap second table
would allow to convert TAI to UTC unambiguously. I think that's what the
conversion routines do for the "right" timezones.
On the other hand, maybe you have seen the discussions elsewhere why you
can't use TAI for the system time for hypothetical reasons. Or at least
you can't call it "TAI".
Martin
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
