Date: Sat, 06 Aug 2005 13:00:24 -0600 (MDT) From: "M. Warner Losh" <imp@bsdimp.com> To: wollman@csail.mit.edu Cc: standards@freebsd.org Subject: Re: Inconsistancy between mktime and system time accross leapsecond Message-ID: <20050806.130024.75615324.imp@bsdimp.com> In-Reply-To: <17140.60527.658336.649822@khavrinen.csail.mit.edu> References: <20050806.001620.82098789.imp@bsdimp.com> <17140.60527.658336.649822@khavrinen.csail.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
In message: <17140.60527.658336.649822@khavrinen.csail.mit.edu>
Garrett Wollman <wollman@csail.mit.edu> writes:
: <<On Sat, 06 Aug 2005 00:16:20 -0600 (MDT), "M. Warner Losh" <imp@bsdimp.com> said:
:
: > mktime, however, when fed a leap second says that it is the first
: > second of the first day of the month (which is the second that gets
: > repeated). posix is silent on what, exactly, to do with leap
: > seconds.
:
: Actually, POSIX is not silent. It says they are to be ignored. From
: XBD section 4.4:
:
: As represented in seconds since the Epoch, each and every day
: shall be accounted for by exactly 86400 seconds.
:
: You can model this as the POSIX epoch advancing by one second for
: every leap second inserted (and similarly for deletions).
Yes. I understand that. The inserted second is the last second of
the day on the day it is inserted. I understand that time_t will be
ambiguous at that time.
: > It gives a formula that seems to support mktime's return value.
: > However, since leap seconds are undefined in posix's time_t epoch, a
: > case can be made for other values.
:
: A case has been made, which has repeatedly been rejected by the POSIX
: committee. If you specify 23:59:60Z, a POSIX implementation *must*
: normalize it to 00:00:00 the following day. If you don't care about
: POSIX compliance, then the code already supports what you want, by
: encoding the leap-second tables into the timezone files. See
: src/share/zoneinfo/Makefile. You'll want to add calls to time2posix()
: and posix2time() to ntpd to adjust kernel times appropriately.
Can you site where this is in the standard or in some followup doc? I
can't find it at all.
I'm not talking about turning on code to keep the leapseconds in the
time_t value. I'm talking about making mktime() return the same value
that the kernel returns during the leap second.
Specifically, the sequence of time at the end of this year will be, on
systems whose time is steered by ntpd or equivalent, will be
time_t UTC time TAI offset TAI since 1970
1136098798 23:59:58 0 (or 32) 1136098830
1136098799 23:59:59 0 (or 32) 1136098831
1136098799 23:59:60 1 (or 33) 1136098832
1136098800 00:00:00 1 (or 33) 1136098833
1136098801 00:00:01 1 (or 33) 1136098834
Since the system time will be 1136098799 during the leap second,
mktime() of that time should also be 1136098799 for that exact
second. Also, to get the TAI time correctrly, the above sequence has
to happen in that order.
You are right that all other :60 situations should normalize to the
next day. There are many things that depend on this behavir.
However, :60 means 'the next second after :59'. For all non-leap
second days, this is the first second of the next day. For leap
second days, this is the repated second...
Who said leap seconds were easy...
Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050806.130024.75615324.imp>