From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: Leap second bug? Date: Mon, 09 Jun 2008 10:58:49 -0400 Message-ID: References: <20080607204054.GA7677@localhost.localdomain> <874p8337ub.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1213023569 11590 80.91.229.12 (9 Jun 2008 14:59:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2008 14:59:29 +0000 (UTC) Cc: guile-user@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Jun 09 17:00:09 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 1K5iqh-0001w1-5j for guile-user@m.gmane.org; Mon, 09 Jun 2008 16:59:55 +0200 Original-Received: from localhost ([127.0.0.1]:58280 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5ipu-00008x-4p for guile-user@m.gmane.org; Mon, 09 Jun 2008 10:59:06 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K5ipp-00005m-9k for guile-user@gnu.org; Mon, 09 Jun 2008 10:59:01 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K5ipn-0008Uk-P2 for guile-user@gnu.org; Mon, 09 Jun 2008 10:59:00 -0400 Original-Received: from [199.232.76.173] (port=54091 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5ipn-0008UO-Gr for guile-user@gnu.org; Mon, 09 Jun 2008 10:58:59 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]:50179) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5ipi-000086-4e; Mon, 09 Jun 2008 10:58:54 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id DBDC652ED; Mon, 9 Jun 2008 10:58:49 -0400 (EDT) X-Hashcash: 1:20:080609:ludo@gnu.org::RH+tHvAUaDZaCMQI:000007o28 X-Hashcash: 1:20:080609:guile-user@gnu.org::i0kRSNEAyt8KsQ4P:0000000000000000000000000000000000000000000Lw9F In-Reply-To: <874p8337ub.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Mon, 09 Jun 2008 00:00:44 +0200") User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/22.1 (berkeley-unix) X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:6606 Archived-At: ludo@gnu.org (Ludovic Court=E8s) writes: > Hi, > > Ondrej Zajicek writes: > >> (use-modules (srfi srfi-19)) >> (define (str->date str) (string->date str "~d-~m-~Y")) >> (define (date->str str) (date->string str "~d-~m-~Y")) >> >> (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? > > Not sure. Our leap second table is up-to-date. Apparently, > `time-utc->date' honors leap seconds, while `date->time-utc' doesn't. > In the reference implementation at schemers.org (upon which Guile's is > based), none of these two honors leap seconds AFAICS. > > I'm no expert in that area but I would suggest emailing the SRFI-19 > mailing list [0] for advice. It seems that most implementations use the > reference implementation with few modifications, in which case most > implementations might be affected. Did you try it with other Scheme > implementations? 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. 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. Plus to have a timescale that tracks UT, which is an astronomical time scale, which is why we have leap seconds. With UTC, one represents seconds since the epoch in a way which does not count leap seconds. With TAI, the count includes all seconds (TAI-UTC curr= ently being 33) (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.) So, I'd say time-utc->date doing any leap second lookups is a bug.