From owner-freebsd-standards@FreeBSD.ORG Sat Aug 6 19:01:33 2005 Return-Path: X-Original-To: standards@freebsd.org Delivered-To: freebsd-standards@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 31DDC16A41F for ; Sat, 6 Aug 2005 19:01:33 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9EFF43D45 for ; Sat, 6 Aug 2005 19:01:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1] (may be forged)) by harmony.bsdimp.com (8.13.3/8.13.3) with ESMTP id j76IxKYU069986; Sat, 6 Aug 2005 12:59:21 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sat, 06 Aug 2005 13:00:24 -0600 (MDT) Message-Id: <20050806.130024.75615324.imp@bsdimp.com> To: wollman@csail.mit.edu From: "M. Warner Losh" 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> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.bsdimp.com [127.0.0.1]); Sat, 06 Aug 2005 12:59:21 -0600 (MDT) Cc: standards@freebsd.org Subject: Re: Inconsistancy between mktime and system time accross leapsecond X-BeenThere: freebsd-standards@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Standards compliance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Aug 2005 19:01:33 -0000 In message: <17140.60527.658336.649822@khavrinen.csail.mit.edu> Garrett Wollman writes: : < 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