Date: Sat, 6 Aug 2005 15:12:49 -0400 From: Garrett Wollman <wollman@csail.mit.edu> To: "M. Warner Losh" <imp@bsdimp.com> Cc: standards@freebsd.org Subject: Re: Inconsistancy between mktime and system time accross leapsecond Message-ID: <17141.2993.393364.510305@khavrinen.csail.mit.edu> In-Reply-To: <20050806.130024.75615324.imp@bsdimp.com> References: <20050806.001620.82098789.imp@bsdimp.com> <17140.60527.658336.649822@khavrinen.csail.mit.edu> <20050806.130024.75615324.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
<<On Sat, 06 Aug 2005 13:00:24 -0600 (MDT), "M. Warner Losh" <imp@bsdimp.com> said: > 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... In POSIX, there are no "leap second days" and "non-leap second days". The behavior of mktime() must be equivalent to the formula in XBD section 4.4. The Standard is clear and conforming implementations must implement the behavior described: # The relationship between the tm structure (defined in the <time.h> # header) and the time in seconds since the Epoch is that the result # shall be as specified in the expression given in the definition of # seconds since the Epoch (see the Base Definitions volume of IEEE Std # 1003.1-2001, Section 4.14, Seconds Since the Epoch) corrected for # timezone and any seasonal time adjustments, where the names in the # structure and in the expression correspond. (XSH page 765 in the original edition of the Standard.) The Standard may be wrong, but the committee has been unable to make progress on this issue in more than a decade of sometimes-contentious debate, so the existing language stands. -GAWollman
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?17141.2993.393364.510305>