From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#26164: time-difference mishandles leap seconds Date: Mon, 5 Nov 2018 11:02:36 +0000 Message-ID: <20181105110236.ypop5ihwnajobcqs@fysh.org> References: <20170318224126.GK6518@fysh.org> <8736syzz61.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1541415670 21012 195.159.176.226 (5 Nov 2018 11:01:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 5 Nov 2018 11:01:10 +0000 (UTC) Cc: 26164@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Nov 05 12:01:06 2018 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJccz-0005MJ-Vb for guile-bugs@m.gmane.org; Mon, 05 Nov 2018 12:01:06 +0100 Original-Received: from localhost ([::1]:34498 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJcf6-0004ft-9s for guile-bugs@m.gmane.org; Mon, 05 Nov 2018 06:03:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37776) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gJcev-0004fU-So for bug-guile@gnu.org; Mon, 05 Nov 2018 06:03:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gJces-0000hJ-EG for bug-guile@gnu.org; Mon, 05 Nov 2018 06:03:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58607) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gJces-0000dB-1t for bug-guile@gnu.org; Mon, 05 Nov 2018 06:03:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gJcer-0003Nk-SB for bug-guile@gnu.org; Mon, 05 Nov 2018 06:03:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 05 Nov 2018 11:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26164 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 26164-submit@debbugs.gnu.org id=B26164.154141576312977 (code B ref 26164); Mon, 05 Nov 2018 11:03:01 +0000 Original-Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 11:02:43 +0000 Original-Received: from localhost ([127.0.0.1]:34632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJceZ-0003NE-4y for submit@debbugs.gnu.org; Mon, 05 Nov 2018 06:02:43 -0500 Original-Received: from river.fysh.org ([87.98.248.19]:41625 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gJceX-0003N4-4O for 26164@debbugs.gnu.org; Mon, 05 Nov 2018 06:02:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fysh.org; s=20170316; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=xv7qG8ux7deqxixCQ4ohYwH3l3vQ6P/fenRQVj1vxAQ=; b=vhWXPN/wvkKM3UsT2BHmPJA5Hm o1O5DJ2Qup63pM+5os/YbuWVNiwfcwj3jl8ChYHwnLcnVCMSmmwrwLyfzmHDVpdsjZCt7lUeHHNPa bfqm5FbNbJSiyLFH0ExE8f9KvqttsIsbXGuD3uWNQgMvjR81P6FgTTPxaaMQQymHyvI8=; Original-Received: from zefram by river.fysh.org with local (Exim 4.89 #1 (Debian)) id 1gJceS-0002Lb-F0; Mon, 05 Nov 2018 11:02:36 +0000 Content-Disposition: inline In-Reply-To: <8736syzz61.fsf@netris.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Original-Sender: "bug-guile" Xref: news.gmane.org gmane.lisp.guile.bugs:9256 Archived-At: Mark H Weaver wrote: >You seem to be assuming that SRFI-19 durations should _always_ represent >intervals of TAI time. No, that is not my position. Although SRFI-19 isn't entirely explicit on this point, it is in the nature of the problem space that a duration may be measured on any time scale, and it seems to be implied that time-difference will determine the duration on the time scale of its inputs. Indeed, if the duration were always to be determined on one specific scale then it would not be necessary for time-difference to require its two inputs to be of the same time type. With respect to UTC, my position is that time-difference on inputs of type time-utc should determine the duration as measured in UTC seconds. For times since 1972 this is always the same as the duration in TAI seconds (elaborated further below). For 1961 to 1971 UTC durations and TAI durations differ, and that's the subject of my bug#26632. Note that in that bug report I explicitly converted time-utc->time-tai where I wanted to determine a TAI duration. > every UTC day has >exactly 86400 UTC seconds, No, that's not how UTC works. There are some time scales derived from UTC that have exactly 86400 seconds for each UTC day, such as Markus Kuhn's UTC-SLS, or that have exactly 86400 seconds per UTC day in the long run, such as Google's "leap smear". But SRFI-19 doesn't refer to any of those, it refers to UTC. The true UTC has a variable number of seconds per day *as judged by UTC clocks*: the days are not merely different lengths as judged by TAI. The variable number of UTC seconds per day is the source of the famous "23:59:60" notation. On a day with a positive leap second, the first second of the day is centred on 00:00:00.5, the 86400th second is centred on 23:59:59.5, and the 86401st second is centred on 23:59:60.5. These are 86401 distinct seconds counted by UTC, each with a distinct label. On a day with a negative leap second, UTC only counts 86399 seconds: the time-of-day labels never reach 23:59:59. It is intrinsic to the definition of UTC that durations (measured in seconds) don't match up regularly with time of day. It's just like the way that intervals measured in days don't match up regularly with day of month: the way to think about a day of UTC is a lot like the way one thinks about a month of the Gregorian calendar. (Though there's an important difference in that we know the lengths of Gregorian months arbitrarily far in advance but only know UTC day lengths months in advance.) Wanting to avoid all that irregularity is the motivation to use UTC-SLS and the like. >Having said all of this, I should admit that I'm not an expert on time >standards, I am. Incidentally, there's an aspect of the present bug report that's different in the pre-1972 era. time-difference correctly shows a duration of exactly 86400 seconds on the UTC scale for an ordinary day in that era, such as 1967-03-14 of which I examined the TAI duration in bug#26632. But it incorrectly shows the same duration for a day with a leap. That's the same error that it makes for post-1972 leaps, but there's a difference in that the duration of the leap (as judged in UTC) is non-integral, being derived from a non-integral number of TAI seconds and also affected by the frequency offset. For example, the UTC duration of 1968-01-31 (also examined in bug#26632) was exactly 8639990259200/100000003 seconds (roughly 86399.900000003 s). This runs into trouble with SRFI-19's insistence that the nanosecond field of a time object only contain an integer. -zefram