From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Keith Wright Newsgroups: gmane.lisp.guile.user Subject: Re: Leap second bug? Date: Mon, 9 Jun 2008 13:18:26 -0400 Message-ID: <200806091718.m59HIQPS013148@fcs13.keithdiane.us> References: <20080607204054.GA7677@localhost.localdomain> <874p8337ub.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org X-Trace: ger.gmane.org 1213032716 14090 80.91.229.12 (9 Jun 2008 17:31:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2008 17:31:56 +0000 (UTC) Cc: ludo@gnu.org, guile-user@gnu.org To: gdt@ir.bbn.com Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jun 09 19:32:39 2008 Return-path: Envelope-to: guile-user@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1K5lEU-0007jY-P8 for guile-user@m.gmane.org; Mon, 09 Jun 2008 19:32:39 +0200 Original-Received: from localhost ([127.0.0.1]:45412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5lDh-0007Wr-DT for guile-user@m.gmane.org; Mon, 09 Jun 2008 13:31:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K5lDb-0007SV-UP for guile-user@gnu.org; Mon, 09 Jun 2008 13:31:43 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K5lDb-0007Qf-1T for guile-user@gnu.org; Mon, 09 Jun 2008 13:31:43 -0400 Original-Received: from [199.232.76.173] (port=45769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5lDa-0007QU-U4 for guile-user@gnu.org; Mon, 09 Jun 2008 13:31:42 -0400 Original-Received: from mail7.sea5.speakeasy.net ([69.17.117.9]:41313) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5lDa-0001DJ-IX for guile-user@gnu.org; Mon, 09 Jun 2008 13:31:42 -0400 Original-Received: (qmail 20550 invoked from network); 9 Jun 2008 17:31:35 -0000 Original-Received: from dsl.keithdiane.us (HELO fcs12.keithdiane.us) ([66.92.74.188]) (envelope-sender ) by mail7.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 9 Jun 2008 17:31:34 -0000 Original-Received: from fcs13.keithdiane.us (fcs13 [192.168.1.112]) by fcs12.keithdiane.us (Postfix) with ESMTP id 9925223784F; Mon, 9 Jun 2008 13:31:48 -0400 (EDT) Original-Received: from fcs13.keithdiane.us (localhost.localdomain [127.0.0.1]) by fcs13.keithdiane.us (Postfix) with ESMTP id C7296AF4043; Mon, 9 Jun 2008 13:18:36 -0400 (EDT) Original-Received: (from kwright@localhost) by fcs13.keithdiane.us (8.13.1/8.13.1/Submit) id m59HIQPS013148; Mon, 9 Jun 2008 13:18:26 -0400 X-Authentication-Warning: fcs13.keithdiane.us: kwright set sender to kwright@keithdiane.us using -f In-reply-to: (message from Greg Troxel on Mon, 09 Jun 2008 10:58:49 -0400) X-detected-kernel: by monty-python.gnu.org: Linux 2.6, seldom 2.4 (older, 4) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:6607 Archived-At: > From: Greg Troxel > > It seems very odd for time-utc->date to pay attention to leap seconds. > I would only expect leap seconds to come into play when converting > between UTC and TAI. Procedure time-utc->date resents the anthropomorphism. The author of that procedure probably paid some attention, but not enough, otherwise the answer would be right. > The whole point of UTC is to have a timescale with the same number > of seconds per day so that one can ignore the mess of leap seconds. I think this is provably false. If anyone wants to argue, I will look up original references, but for now I will just quote something I wrote a few years ago, after spending much more time on this issue than all the leap seconds in the history of the universe. > UTC can not be expressed as a single number (in any units), but must > be expressed as a day (either Julian Day or Gregorian Calendar > Date), together with a time within that day (expressed as hours, > minutes, and seconds, as total number of seconds, or as a fraction > of a day). This is because the days are not all the same length. > Most of them are $86\,400$ seconds (exactly), but when a leap second > is inserted the day is $86\,401$ seconds (exactly). > With UTC, one represents seconds since the epoch in a way which does > not count leap seconds. UTC is _not_ expressed in seconds. If it were, it would be messed up whenever a second passed without incrementing the count. > With TAI, the count includes all seconds > (TAI-UTC currently being 33) This true (to within a second) and explains why we don't use TIA much. It's too hard to figure out the date, which the boss cares about. > (I would say that a time difference of two UTC times should return > the arithmetic difference of the two seconds-since-epoch values, and > of two TAI times the same thing, but the TAI ones will have leap > seconds. This is not clear in the srfi-19 text.) The srfi says the input to time-utc->date is a of type time-utc. I don't find a definition of that in the srfi. (There is a symbol with that name, but no type.) It probably means a time object with component time-type set to the symbol time-utc. This is bad, because a time object is a count of seconds, and UTC is not. > So, I'd say time-utc->date doing any leap second lookups is a bug. I don't know what a procedure should do if it is based upon a spec that violates international standards. > > Ondrej Zajicek writes: > > > >> (date->str (time-utc->date (date->time-utc (str->date "01-01-2006")))) > >> -> "31-12-2005" > >> > >> Is is a bug in leap second handling or is it a expected behavior? I am open to argument on other things, but I am sure that if this is expected behavior, it is bug in someone's expectations. -- Keith