Received: (at 26164) by debbugs.gnu.org; 6 Nov 2018 00:13:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 05 19:13:42 2018
Received: from localhost ([127.0.0.1]:35846 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gJp01-0001Ro-SU
for submit <at> debbugs.gnu.org; Mon, 05 Nov 2018 19:13:42 -0500
Received: from world.peace.net ([64.112.178.59]:60746)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1gJozz-0001Rb-NJ
for 26164 <at> debbugs.gnu.org; Mon, 05 Nov 2018 19:13:40 -0500
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1gJozu-0003Ck-1n; Mon, 05 Nov 2018 19:13:34 -0500
From: Mark H Weaver <mhw@HIDDEN>
To: Zefram <zefram@HIDDEN>
Subject: Re: bug#26164: time-difference mishandles leap seconds
References: <20170318224126.GK6518@HIDDEN> <8736syzz61.fsf@HIDDEN>
<20181105110236.ypop5ihwnajobcqs@HIDDEN>
Date: Mon, 05 Nov 2018 19:12:49 -0500
In-Reply-To: <20181105110236.ypop5ihwnajobcqs@HIDDEN> (Zefram's message of
"Mon, 5 Nov 2018 11:02:36 +0000")
Message-ID: <871s7znjvn.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 26164
Cc: 26164 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Zefram <zefram@HIDDEN> writes:
> Mark H Weaver wrote:
>> 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.
BTW, I discussed this with John Cowan at length in bug 22034, starting
at message #19:
https://bugs.gnu.org/22034#19
In particular, I would be curious to know how you would fill in the same
table that John attempted to fill in, here:
https://bugs.gnu.org/22034#55
What numbers would you write in the second column of those tables?
Thanks,
Mark
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.
Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 20:47:16 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 05 15:47:16 2018
Received: from localhost ([127.0.0.1]:35708 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gJlmF-0002ov-4C
for submit <at> debbugs.gnu.org; Mon, 05 Nov 2018 15:47:16 -0500
Received: from world.peace.net ([64.112.178.59]:60456)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1gJlmD-0002oh-2z
for 26164 <at> debbugs.gnu.org; Mon, 05 Nov 2018 15:47:13 -0500
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1gJlm7-00027C-AS; Mon, 05 Nov 2018 15:47:07 -0500
From: Mark H Weaver <mhw@HIDDEN>
To: Zefram <zefram@HIDDEN>
Subject: Re: bug#26164: time-difference mishandles leap seconds
References: <20170318224126.GK6518@HIDDEN> <8736syzz61.fsf@HIDDEN>
<20181105110236.ypop5ihwnajobcqs@HIDDEN>
Date: Mon, 05 Nov 2018 15:46:24 -0500
In-Reply-To: <20181105110236.ypop5ihwnajobcqs@HIDDEN> (Zefram's message of
"Mon, 5 Nov 2018 11:02:36 +0000")
Message-ID: <87pnvjntfo.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 26164
Cc: 26164 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Zefram <zefram@HIDDEN> writes:
> Mark H Weaver wrote:
>>Having said all of this, I should admit that I'm not an expert on time
>>standards,
>
> I am.
Okay, you claim to be one, and maybe you're right, but I've also done a
great deal of research on this recently and in the past, and I'm not yet
convinced.
If you're right that there's still a problem, please post to the SRFI-19
mailing list and engage with the time experts there. If you can
convince them to change the behavior of 'time-difference' in their
reference implementation, then I'll be glad to merge those changes into
Guile.
Thanks,
Mark
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.
Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 13:48:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 05 08:48:07 2018
Received: from localhost ([127.0.0.1]:34694 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gJfEc-0000yx-VH
for submit <at> debbugs.gnu.org; Mon, 05 Nov 2018 08:48:07 -0500
Received: from mail-wr1-f46.google.com ([209.85.221.46]:44758)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <cowan@HIDDEN>) id 1gJfEZ-0000yT-Rs
for 26164 <at> debbugs.gnu.org; Mon, 05 Nov 2018 08:48:05 -0500
Received: by mail-wr1-f46.google.com with SMTP id j17-v6so4463715wrq.11
for <26164 <at> debbugs.gnu.org>; Mon, 05 Nov 2018 05:48:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=ccil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=CFUjDHY8mGnu9Eo2F9InI7SzsV+MxOBvkHd/kMcgrN0=;
b=Smx+vt/R47rpv0CjzZD94mIgfaRgYrWej+cKLvHVysw3O93izpKtZW++R0jQ4lIozU
XiFMXdU1QCGtLztGrJzBvPHQJ0oxC1Pmi6HmBdhNN8zHdvQ/RZ584EH/dTJP9hfZl3LP
wqwu6FMUN5NHMS606O8U+1ArWbYf7TWLSZtBXvuX/R9fKjswOR4iQg2WY30x0lzKQds1
PDo99XMrBhxwwbxPQUGmTnOSenqKFZEeRAR4CfqqWHzhkpIt5LuSKWCbtiFFzrXmeOmz
mgOm4JUBhiSUZi3knC5/10wzNzEiCRWWxkQHwot1w+paXuWUOAAtdqMWevM+UnkQAG/k
OLfg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=CFUjDHY8mGnu9Eo2F9InI7SzsV+MxOBvkHd/kMcgrN0=;
b=hYQKz2pZxZAril9nETBTlhXg9iEfx1xNgiwpLRDQbayYsK8qXALJjNlTvsBIUm2ljz
y/4QfQdb/5tCBXvRt4CSAjODRt7pFp4PcZDH2tW6zpM2hg0pG9IuYurdT4Yxhp6m7ioy
HwdBwDLZ3YPMfpT1M5rIh+Rkmc4y7iWXLKopSV5GjCHVy1hLr+ClSmQJ5V8EcUt7pSos
q1ZVh3zPt52hjCeITsWTqa4QcEudrU/Lo439ONndlzSh7FOs9/x87QrKTnQV9rA4tCdu
syXnJTA8q1MBkjbLBsSvuq17zotFrL8vu2iAZk4VwE8Hk97qWtXyee+bGlYT4POZD0A1
ZuHA==
X-Gm-Message-State: AGRZ1gJa3orNSbsIJDc+JDCCQZq4GEWgV6PEH6W390NC3JCxporBO4X5
1O6v/xHaZnblLv3MAruYFka1ZgPRbFjLe6J0Ye7MeQ==
X-Google-Smtp-Source: AJdET5dVq84LWEsVnZcab7SehlvjI2O6aQqRtS/oHJlsR7RILj4GQ1I4SYm82olVg4z4Z0d5M/efoCXebUqobG+q64g=
X-Received: by 2002:adf:ae09:: with SMTP id
x9-v6mr18784193wrc.102.1541425677745;
Mon, 05 Nov 2018 05:47:57 -0800 (PST)
MIME-Version: 1.0
References: <20170318224126.GK6518@HIDDEN> <8736syzz61.fsf@HIDDEN>
<20181105110236.ypop5ihwnajobcqs@HIDDEN>
In-Reply-To: <20181105110236.ypop5ihwnajobcqs@HIDDEN>
From: John Cowan <cowan@HIDDEN>
Date: Mon, 5 Nov 2018 08:47:46 -0500
Message-ID: <CAD2gp_R5d21iORE2V87DYs99MCULpyPgZOduUudO5xJL--rmfw@HIDDEN>
Subject: Re: bug#26164: time-difference mishandles leap seconds
To: zefram@HIDDEN
Content-Type: multipart/alternative; boundary="000000000000f856720579eb21ce"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 26164
Cc: Mark H Weaver <mhw@HIDDEN>, 26164 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--000000000000f856720579eb21ce
Content-Type: text/plain; charset="UTF-8"
On Mon, Nov 5, 2018 at 6:03 AM Zefram <zefram@HIDDEN> wrote:
Mark H Weaver wrote:
>
> No, that's not how UTC works.
Everything Zefram says is what I was trying to say and failing.
I would only add that:
1) TAI-UTC refers to broken-down time, not to the count
of seconds since some epoch. TAI-UTC is currently 37 seconds, which means
that at 2018-11-05T13:43:00 UTC time (approximately when I am writing this)
it is
2018-11-05T13:43:37 TAI time.
2) Posix time, unlike UTC really does label leap seconds with the same
integer as the
preceding second.
> >Having said all of this, I should admit that I'm not an expert on time
> >standards,
>
> I am.
>
He is.
--
John Cowan http://vrici.lojban.org/~cowan cowan@HIDDEN
There is no real going back. Though I may come to the Shire, it will
not seem the same; for I shall not be the same. I am wounded with
knife, sting, and tooth, and a long burden. Where shall I find rest?
--Frodo
--000000000000f856720579eb21ce
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br><br><div class=3D"gmail_quote"><div d=
ir=3D"ltr">On Mon, Nov 5, 2018 at 6:03 AM Zefram <<a href=3D"mailto:zefr=
am@HIDDEN">zefram@HIDDEN</a>> wrote:<br></div><div dir=3D"ltr"><br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">Mark H Weaver wrote:=
<br><br>
No, that's not how UTC works.</blockquote><div><br></div><div>Everythin=
g Zefram says is what I was trying to say and failing.</div><div><br></div>=
<div>I would only add that:</div><div><br></div><div>1) TAI-UTC refers to b=
roken-down time, not to the count</div><div>of seconds since some epoch.=C2=
=A0 TAI-UTC is currently 37 seconds, which means</div><div>that at 2018-11-=
05T13:43:00 UTC time (approximately when I am writing this) it is</div><div=
>2018-11-05T13:43:37 TAI time.</div><div><br></div><div>2) Posix time, unli=
ke UTC really does label leap seconds with the same integer as the</div><di=
v>preceding second.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote"=
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex">>Having said all of this, I should admit that I'm n=
ot an expert on time<br>
>standards,<br>
<br>
I am.<br></blockquote><div><br></div><div>He is.</div><div><br></div><div>-=
-=C2=A0</div><div><div>John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=
=3D"http://vrici.lojban.org/~cowan">http://vrici.lojban.org/~cowan</a>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"mailto:cowan@HIDDEN">cowan@HIDDEN</=
a></div><div>There is no real going back.=C2=A0 Though I may come to the Sh=
ire, it will</div><div>not seem the same; for I shall not be the same.=C2=
=A0 I am wounded with</div><div>knife, sting, and tooth, and a long burden.=
=C2=A0 Where shall I find rest?</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 --Frodo</div></div><div><br></div></div></div></di=
v>
--000000000000f856720579eb21ce--
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 11:02:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 05 06:02:43 2018 Received: from localhost ([127.0.0.1]:34632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1gJceZ-0003NE-4y for submit <at> debbugs.gnu.org; Mon, 05 Nov 2018 06:02:43 -0500 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 <zefram@HIDDEN>) id 1gJceX-0003N4-4O for 26164 <at> 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=; 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 Date: Mon, 5 Nov 2018 11:02:36 +0000 From: Zefram <zefram@HIDDEN> To: Mark H Weaver <mhw@HIDDEN> Subject: Re: bug#26164: time-difference mishandles leap seconds Message-ID: <20181105110236.ypop5ihwnajobcqs@HIDDEN> References: <20170318224126.GK6518@HIDDEN> <8736syzz61.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8736syzz61.fsf@HIDDEN> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 26164 Cc: 26164 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) 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
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.
Received: (at 26164) by debbugs.gnu.org; 21 Oct 2018 22:57:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 21 18:57:17 2018
Received: from localhost ([127.0.0.1]:34857 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1gEMer-00072D-HT
for submit <at> debbugs.gnu.org; Sun, 21 Oct 2018 18:57:17 -0400
Received: from world.peace.net ([64.112.178.59]:36496)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <mhw@HIDDEN>) id 1gEMep-00071y-HC
for 26164 <at> debbugs.gnu.org; Sun, 21 Oct 2018 18:57:15 -0400
Received: from mhw by world.peace.net with esmtpsa
(TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89)
(envelope-from <mhw@HIDDEN>)
id 1gEMej-0003H3-DS; Sun, 21 Oct 2018 18:57:09 -0400
From: Mark H Weaver <mhw@HIDDEN>
To: Zefram <zefram@HIDDEN>
Subject: Re: bug#26164: time-difference mishandles leap seconds
References: <20170318224126.GK6518@HIDDEN>
Date: Sun, 21 Oct 2018 18:56:54 -0400
In-Reply-To: <20170318224126.GK6518@HIDDEN> (Zefram's message of "Sat, 18
Mar 2017 22:41:26 +0000")
Message-ID: <8736syzz61.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 26164
Cc: 26164 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Zefram <zefram@HIDDEN> writes:
> Computing the duration of the period between two UTC times, using
> SRFI-19 mechanisms:
>
> scheme@(guile-user)> (use-modules (srfi srfi-19))
> scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0)))
> scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0)))
> scheme@(guile-user)> (time-difference t1 t0)
> $1 = #<time type: time-duration nanosecond: 0 second: 2>
>
> The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at
> first glance one would expect the duration to be 2 s as shown above,
> the two seconds being 23:59:59 and 00:00:00. But in fact there was
> a leap second 2012-06-30T23:59:60, so the duration of this period is
> actually 3 s.
You seem to be assuming that SRFI-19 durations should _always_ represent
intervals of TAI time. While I agree that TAI time is often the right
choice for durations, there are other cases where monotonic time is a
better choice. Currently, monotonic time == TAI time, but SRFI-19 makes
it clear that this needn't be the case, and at some point we might want
to change monotonic time to be _truly_ monotonic, even in cases where
the system clock jumps backward.
Durations in UTC time have uses as well. For example, every UTC day has
exactly 86400 UTC seconds, so (make-time time-duration 0 86400) means 1
UTC day, when added to a UTC time. This is a duration that, when added
to any UTC time, always leaves the time-of-day unchanged. There is no
fixed duration of TAI time that has this property, because not all UTC
days have the same number of TAI seconds.
> [...] Since 1972, the seconds of UTC are of exactly
> the same duration as the seconds of TAI. (They're also phase-locked to
> TAI seconds.) Thus the period of three TAI seconds is also a period of
> three UTC seconds. It is not somehow squeezed into two UTC seconds.
I believe you are mistaken here. Not all UTC seconds have the same
duration as a TAI second. Some TAI seconds correspond to 0 UTC seconds,
and maybe some day there will be a TAI second that corresponds to 2 UTC
seconds.
Having said all of this, I should admit that I'm not an expert on time
standards, so perhaps I've misunderstood something.
What do you think?
Mark
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.Received: (at 26164) by debbugs.gnu.org; 19 Apr 2017 16:22:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 19 12:22:08 2017 Received: from localhost ([127.0.0.1]:57195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1d0sMq-0004fT-9O for submit <at> debbugs.gnu.org; Wed, 19 Apr 2017 12:22:08 -0400 Received: from river.fysh.org ([87.98.248.19]:54157 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zefram@HIDDEN>) id 1d0sMo-0004fL-NO for 26164 <at> debbugs.gnu.org; Wed, 19 Apr 2017 12:22:07 -0400 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:To:From:Date; bh=ZjkJ0wtPP5RjEoTTrfG2S+NQlBKtFsKJYZKUfcc3PJE=; b=M79i4kUWtMTxi40ku90mh5pCfBAVu7i2PArS+WCxLwXaqGZ073kFLEiQAGlygCbPIwgtdm6jmus/42XBMEDA+Ctv2m2Jo0L5Zk7o/uolXIej8YldZya80KmzC3pEVQyhQ0hePbMTuPbQ1FRxqQydbZPF6xwk9iZjHDkOj9iNWyA=; Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian)) id 1d0sMl-0005Rw-Ra; Wed, 19 Apr 2017 17:22:03 +0100 Date: Wed, 19 Apr 2017 17:22:03 +0100 From: Zefram <zefram@HIDDEN> To: 26164 <at> debbugs.gnu.org Subject: Re: bug#26164: time-difference mishandles leap seconds Message-ID: <20170419162203.GE6765@HIDDEN> References: <20170318224126.GK6518@HIDDEN> <87d1c8mprz.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87d1c8mprz.fsf@HIDDEN> X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 26164 X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.0 (/) Andy Wingo wrote: >Makes sense to me. Would you like to submit a patch and test case? This particular bug has interactions with other bugs that make me uncomfortable about attempting to fix it right now. The right way to fix this is especially influenced by the approach taken to bug#22033 and to the bug regarding pre-1972 UTC. The latter I haven't even reported yet because it's difficult to formulate in the presence of some of the other UTC-related bugs such as bug#21911 and bug#21912. So I think this is one to postpone until some of those are out of the way. -zefram
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.Received: (at 26164) by debbugs.gnu.org; 19 Apr 2017 14:32:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 19 10:32:43 2017 Received: from localhost ([127.0.0.1]:56999 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1d0qex-0001jv-5H for submit <at> debbugs.gnu.org; Wed, 19 Apr 2017 10:32:43 -0400 Received: from pb-sasl2.pobox.com ([64.147.108.67]:57376 helo=sasl.smtp.pobox.com) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <wingo@HIDDEN>) id 1d0qev-0001jn-8M for 26164 <at> debbugs.gnu.org; Wed, 19 Apr 2017 10:32:41 -0400 Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id E16438334D; Wed, 19 Apr 2017 10:32:39 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type; s=sasl; bh=FTEEZTN76mJpzO2sqBZVN8tJ8Gs=; b=xYqQ9R i/oWU9e7PcjHss50DXpBANCrEQuxGKRK2eAbeqMGKROARU21Zucl21/UcX8ecZhp UIOkdky/SJWhvCuJU4xFVKItmnhiRQtLI4XaeEreOExzF3Jv8dM2Hi2rNV6RJcOi ai3FXrhT6A8MxGjeweS9LZuIZbrYGp+9EARmA= Received: from pb-sasl2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id D8D6B8334C; Wed, 19 Apr 2017 10:32:39 -0400 (EDT) Received: from rusty (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl2.pobox.com (Postfix) with ESMTPSA id 211C183349; Wed, 19 Apr 2017 10:32:39 -0400 (EDT) From: Andy Wingo <wingo@HIDDEN> To: Zefram <zefram@HIDDEN> Subject: Re: bug#26164: time-difference mishandles leap seconds References: <20170318224126.GK6518@HIDDEN> Date: Wed, 19 Apr 2017 16:32:32 +0200 In-Reply-To: <20170318224126.GK6518@HIDDEN> (zefram@HIDDEN's message of "Sat, 18 Mar 2017 22:41:26 +0000") Message-ID: <87d1c8mprz.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Pobox-Relay-ID: 0A1DD5EC-250D-11E7-8E8B-571C92A0D1B0-02397024!pb-sasl2.pobox.com X-Spam-Score: 0.7 (/) X-Debbugs-Envelope-To: 26164 Cc: 26164 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: 0.7 (/) On Sat 18 Mar 2017 23:41, Zefram <zefram@HIDDEN> writes: > Computing the duration of the period between two UTC times, using > SRFI-19 mechanisms: > > scheme@(guile-user)> (use-modules (srfi srfi-19)) > scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0))) > scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0))) > scheme@(guile-user)> (time-difference t1 t0) > $1 = #<time type: time-duration nanosecond: 0 second: 2> > > The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at > first glance one would expect the duration to be 2 s as shown above, > the two seconds being 23:59:59 and 00:00:00. But in fact there was > a leap second 2012-06-30T23:59:60, so the duration of this period is > actually 3 s. The SRFI-19 library is aware of this leap second, and > will compute the duration correctly if it's translated into TAI: > > scheme@(guile-user)> (time-difference (time-utc->time-tai t1) (time-utc->time-tai t0)) > $2 = #<time type: time-duration nanosecond: 0 second: 3> > > The original computation in UTC space should yield a result of 3 s, > not the 2 s that it did. Since 1972, the seconds of UTC are of exactly > the same duration as the seconds of TAI. (They're also phase-locked to > TAI seconds.) Thus the period of three TAI seconds is also a period of > three UTC seconds. It is not somehow squeezed into two UTC seconds. Makes sense to me. Would you like to submit a patch and test case? I would be happy to apply it. Andy
bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.Received: (at submit) by debbugs.gnu.org; 18 Mar 2017 22:41:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 18 18:41:41 2017 Received: from localhost ([127.0.0.1]:34400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1cpN2b-00040j-3V for submit <at> debbugs.gnu.org; Sat, 18 Mar 2017 18:41:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:53843) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <zefram@HIDDEN>) id 1cpN2Z-00040T-6g for submit <at> debbugs.gnu.org; Sat, 18 Mar 2017 18:41:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1cpN2T-0008FU-0A for submit <at> debbugs.gnu.org; Sat, 18 Mar 2017 18:41:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:34389) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1cpN2S-0008FP-T6 for submit <at> debbugs.gnu.org; Sat, 18 Mar 2017 18:41:32 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:44812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1cpN2R-0008Fm-RN for bug-guile@HIDDEN; Sat, 18 Mar 2017 18:41:32 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1cpN2R-0008F6-3S for bug-guile@HIDDEN; Sat, 18 Mar 2017 18:41:31 -0400 Received: from river6.fysh.org ([2001:41d0:d:20da::2]:55942 helo=river.fysh.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from <zefram@HIDDEN>) id 1cpN2Q-0008Ey-Q8 for bug-guile@HIDDEN; Sat, 18 Mar 2017 18:41:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=fysh.org; s=20170316; h=Content-Type:MIME-Version:Message-ID:Subject:To:From:Date; bh=HDKgZd6yXaX1LLpgetNzAx30ufmdL1ZkJYdrW7XFlks=; b=vQoa+UZ8YwWfwp4NHXeLn+KVQxzOnhhmFrRRpabaXo4EsfjisDQvq9fVW5nExlDtlEOZ1518eyLggs+JbGBN9pX72VRGN12YTbJfWDfbEgskK9ZNtGCE90Id429pJGaVxRjOhxyFrW1JL2FkQu3LCnD7gLPNWRf0pMWyK7HkN8s=; Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian)) id 1cpN2M-0005Ah-Hy; Sat, 18 Mar 2017 22:41:26 +0000 Date: Sat, 18 Mar 2017 22:41:26 +0000 From: Zefram <zefram@HIDDEN> To: bug-guile@HIDDEN Subject: time-difference mishandles leap seconds Message-ID: <20170318224126.GK6518@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -4.0 (----) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -4.0 (----) Computing the duration of the period between two UTC times, using SRFI-19 mechanisms: scheme@(guile-user)> (use-modules (srfi srfi-19)) scheme@(guile-user)> (define t0 (date->time-utc (make-date 0 59 59 23 30 6 2012 0))) scheme@(guile-user)> (define t1 (date->time-utc (make-date 0 1 0 0 1 7 2012 0))) scheme@(guile-user)> (time-difference t1 t0) $1 = #<time type: time-duration nanosecond: 0 second: 2> The two times are 2012-06-30T23:59:59 and 2012-07-01T00:00:01, so at first glance one would expect the duration to be 2 s as shown above, the two seconds being 23:59:59 and 00:00:00. But in fact there was a leap second 2012-06-30T23:59:60, so the duration of this period is actually 3 s. The SRFI-19 library is aware of this leap second, and will compute the duration correctly if it's translated into TAI: scheme@(guile-user)> (time-difference (time-utc->time-tai t1) (time-utc->time-tai t0)) $2 = #<time type: time-duration nanosecond: 0 second: 3> The original computation in UTC space should yield a result of 3 s, not the 2 s that it did. Since 1972, the seconds of UTC are of exactly the same duration as the seconds of TAI. (They're also phase-locked to TAI seconds.) Thus the period of three TAI seconds is also a period of three UTC seconds. It is not somehow squeezed into two UTC seconds. -zefram
Zefram <zefram@HIDDEN>:bug-guile@HIDDEN.
Full text available.bug-guile@HIDDEN:bug#26164; Package guile.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.