Inconsistancy between mktime and system time accross leapsecond

[M. Warner Losh]

In message: <17140.60527.658336.649822 at khavrinen.csail.mit.edu>
            Garrett Wollman <wollman at csail.mit.edu> writes:
: <<On Sat, 06 Aug 2005 00:16:20 -0600 (MDT), "M. Warner Losh" <imp at 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