From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Cowan Newsgroups: gmane.lisp.guile.bugs Subject: bug#22034: time-utc->date shows bogus zone-dependent leap second Date: Sun, 28 Oct 2018 19:58:03 -0400 Message-ID: References: <20151127195146.GB28472@fysh.org> <87a7n847o5.fsf@netris.org> <87va5u8q7o.fsf@netris.org> <871s89ajql.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c75750057952b9a9" X-Trace: blaine.gmane.org 1540771037 31594 195.159.176.226 (28 Oct 2018 23:57:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 28 Oct 2018 23:57:17 +0000 (UTC) Cc: zefram@fysh.org, 22034@debbugs.gnu.org, 22034-done@debbugs.gnu.org To: Mark H Weaver Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Oct 29 00:57:12 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 1gGuvf-00086N-0S for guile-bugs@m.gmane.org; Mon, 29 Oct 2018 00:57:11 +0100 Original-Received: from localhost ([::1]:42670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGuxl-00049f-FX for guile-bugs@m.gmane.org; Sun, 28 Oct 2018 19:59:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59403) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gGuxZ-00042g-KD for bug-guile@gnu.org; Sun, 28 Oct 2018 19:59:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gGuxU-0007P9-Tf for bug-guile@gnu.org; Sun, 28 Oct 2018 19:59:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45217) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gGuxS-0007ON-VE for bug-guile@gnu.org; Sun, 28 Oct 2018 19:59:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gGuxS-0004bb-SK for bug-guile@gnu.org; Sun, 28 Oct 2018 19:59:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: John Cowan Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Sun, 28 Oct 2018 23:59:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22034 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 22034-done@debbugs.gnu.org id=D22034.154077110317642 (code D ref 22034); Sun, 28 Oct 2018 23:59:02 +0000 Original-Received: (at 22034-done) by debbugs.gnu.org; 28 Oct 2018 23:58:23 +0000 Original-Received: from localhost ([127.0.0.1]:49472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGuwo-0004aT-OI for submit@debbugs.gnu.org; Sun, 28 Oct 2018 19:58:23 -0400 Original-Received: from mail-wr1-f41.google.com ([209.85.221.41]:40395) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gGuwm-0004aA-Gy for 22034-done@debbugs.gnu.org; Sun, 28 Oct 2018 19:58:21 -0400 Original-Received: by mail-wr1-f41.google.com with SMTP id i17-v6so6709024wre.7 for <22034-done@debbugs.gnu.org>; Sun, 28 Oct 2018 16:58:20 -0700 (PDT) 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=JI8ujwS2hnZ1c+r98mGPuRv12Mem8rz+ByNw/9noY+4=; b=fHn2mNDyb0sBn59kFQ7bBcooNTJtiJT3kUrQQSBSWYFpceWNUwslKHnRjoB1njKrs2 BJUx7nJmbFfiPykN6ZB1ITj4MC1c3gdJ9Ns2dK9jZU5fB8ZRHEUTXgB4NRmhKBi1LGPs vxsATefoMFy8ht83j9P8mRs8M/SCE33jEcv9SqATvT4GRlzKVgkZScJw3igJC6BTi0yD ihPuFo8NkccF71Uy+0Y30Ddx0OqJjFUKOTq7PzUu+fC2Oi81iTt7U8l/Sb50AXS7VXGx bR5ts61vo2EybIjg5zn4EvZLUEhwrs4kQlM0SH5Rp3p6zEnIpLGm0HRmOJtZwvH4aWJ3 rzOA== 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=JI8ujwS2hnZ1c+r98mGPuRv12Mem8rz+ByNw/9noY+4=; b=X4oFNyuL0Wqe7Y1Xka0ICAlI+sLrN9dzNSK9gDVpDwVaBvbC6d725UmdT2Kk3+70SK iVZ6m+F3ExYD5wxUz6cmWgDB3EDd00n8ii645gX9y1P0NSUg7GjfaUgTmBNo/zqUPHpr e07Q9XFPFXDTrsXeD1eA6UIzcnmqVNVCGVI7WCDTpyPl6qrZX3TfGyMD/4Ju7hV7yTQ6 iYXpo7+I54dALB0melwr9ZvqOG29hX8yuIUGRyr/IRIXOJy0xpv+uY6SZeXHGZeSnmV8 zb5AHJ88+3cUsciV3PZ1ZvBYUOATsVYU9unVY3hin4KGsuA4EFa+DnSqukK92HDqN+v0 nIcA== X-Gm-Message-State: AGRZ1gKbZkIOEf9zRKiS6yhUjxRSAdwMGTpfzDXp/lLNhRivu+8n8d2Q eFZQDSTY5YglNl0n5J6RGLyZmSdeUJzLdtTv9oTqfQ== X-Google-Smtp-Source: AJdET5cLWhj8feht+eiyhWdme+6DvHNMmtxygGQ9qXLgJb8Q+tdTeAuzfHHfCYolMpb6QYB0g/1gsKrMn5TTtd2xuVU= X-Received: by 2002:adf:e307:: with SMTP id b7-v6mr13511151wrj.91.1540771094674; Sun, 28 Oct 2018 16:58:14 -0700 (PDT) In-Reply-To: <871s89ajql.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:9248 Archived-At: --000000000000c75750057952b9a9 Content-Type: text/plain; charset="UTF-8" On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver wrote: I believe you're making a subtle error in your identification of UTC > seconds with TAI seconds. And I in turn think you (or perhaps someone else)are making an error in your use of the term "UTC". > A TAI clock aims to measure the current TAI time, i.e. to measure the > time interval between the epoch and _you_ in units of TAI seconds, > i.e. SI seconds as observed on the geoid. > > In spatial terms, a TAI clock is analogous to a very precise measuring > tape which aims to measure the distance between you and an fixed > conventional point in space, analogous to the TAI epoch. > We agree so far. > In this analogy, a UTC clock is analogous to an equally precise > measuring tape that is _almost_ identical to the TAI analogue measuring > tape, but subtly different. If we place the two measuring tapes side by > side and ignore pre-1972, we see that the markings are in _precisely_ > the same positions along the entire length of the tape, without the > slightest deviation, even over long distances. > > The difference between the two measuring tapes is that they assign > different numbers to the markings, and moreover that the UTC analogue > has a small handful of places where two adjacent markings have the same > number assigned, and all subsequent numbers are shifted by 1. Now I think you are entirely right here, modulo a single term: what you are calling "UTC", I call (and I think correctly), "Posix". It is Posix time that has two identical adjacent markings. 126230400 |------------ > 126230400 |------------ > The numbers here are not UTC seconds since the Epoch, but Posix seconds since the Epoch. In short, there are exactly 86400 Posix seconds in a mean solar day, whereas in UTC reckoning there are exactly 1440 minutes, of which some may contain more (or less) than 60 seconds. That is why UTC clocks displayed 2016-12-13T23:59:60 during the last leap second. Computer clocks are normally Posix rather than UTC clocks, and the difference does not matter very often. > $1 = ((126230410 "1973-12-31T23:59:58Z") > (126230411 "1973-12-31T23:59:59Z") > (126230412 "1973-12-31T23:59:60Z") > (126230413 "1974-01-01T00:00:00Z") > (126230414 "1974-01-01T00:00:01Z")) > --8<---------------cut here---------------end--------------->8-- Good. > > If I understand correctly, 'time-utc->date' should never return a date > > object with 60 in the seconds field, because those extra seconds have no > > representation in time-utc. They only have representations in time-tai > > and time-monotonic. > Same story. Leap seconds have no representation in Posix time, but they do in UTC time. > As you can see, 1973-12-31T23:59:60Z and 1974-01-01T00:00:00Z have the > same representation in TIME-UTC. That is because what is called UTC time is in fact Posix time. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org It was impossible to inveigle Georg Wilhelm Friedrich Hegel Into offering the slightest apology For his Phenomenology. --W. H. Auden, from "People" (1953) --000000000000c75750057952b9a9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver <mhw@netris.org> wrote:

I believe you&= #39;re making a subtle error in your identification of UTC
seconds with TAI seconds.=C2=A0

And I in t= urn think you (or perhaps someone else)are making an error
in you= r use of the term "UTC".
=C2=A0
A TAI clock aims to measure the current TA= I time, i.e. to measure the
time interval between the epoch and _you_ in units of TAI seconds,
i.e. SI seconds as observed on the geoid.

In spatial terms, a TAI clock is analogous to a very precise measuring
tape which aims to measure the distance between you and an fixed
conventional point in space, analogous to the TAI epoch.

We agree so far.
=C2=A0
In this analogy, a UTC clock is analogous to an equally precise
measuring tape that is _almost_ identical to the TAI analogue measuring
tape, but subtly different.=C2=A0 If we place the two measuring tapes side = by
side and ignore pre-1972, we see that the markings are in _precisely_
the same positions along the entire length of the tape, without the
slightest deviation, even over long distances.

The difference between the two measuring tapes is that they assign
different numbers to the markings, and moreover that the UTC analogue
has a small handful of places where two adjacent markings have the same
number assigned, and all subsequent numbers are shifted by 1.
<= div>
Now I think you are entirely right here, modulo a single= term: what you are
calling "UTC", I call (and I think = correctly), "Posix".=C2=A0 It is Posix time that
has tw= o identical adjacent markings.

=C2=A0 126230400 |------------
=C2=A0 126230400 |------------

The numb= ers here are not UTC seconds since the Epoch, but Posix seconds
s= ince the Epoch.=C2=A0 In short, there are exactly 86400 Posix seconds in a = mean
solar day, whereas in UTC reckoning there are exactly 1440 m= inutes, of which=C2=A0
some may contain more (or less) than 60 se= conds.=C2=A0 That is why UTC clocks
displayed 2016-12-13T23:59:60= during the last leap second.=C2=A0 Computer clocks
are normally = Posix rather than UTC clocks, and the difference does not matter
= very often.
=C2=A0
=C2=A0
$1 =3D ((126230410 "1973-12-31T23:59:58Z")
=C2=A0 =C2=A0 =C2=A0 (126230411 "1973-12-31T23:59:59Z")
=C2=A0 =C2=A0 =C2=A0 (126230412 "1973-12-31T23:59:60Z")
=C2=A0 =C2=A0 =C2=A0 (126230413 "1974-01-01T00:00:00Z")
=C2=A0 =C2=A0 =C2=A0 (126230414 "1974-01-01T00:00:01Z"))
--8<---------------cut here---------------end--------------->8--

Good.
=C2=A0
>=C2=A0 If I understand correctly, '= ;time-utc->date' should never return a date
>=C2=A0 object with 60 in the seconds field, because those extra seconds= have no
>=C2=A0 representation in time-utc.=C2=A0 They only have representations= in time-tai
>=C2=A0 and time-monotonic.

Same sto= ry.=C2=A0 Leap seconds have no representation in Posix time, but they
=
do in UTC time.
=C2=A0
As you can see, 1973-12-31T23:59:60Z and 1974-01-01T00:00= :00Z have the
same representation in TIME-UTC.

That is be= cause what is called UTC time is in fact Posix time.

--=C2=A0=
John Cowan=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 http://vrici.lojban.org/~cowan=C2=A0 =C2= =A0 =C2=A0 =C2=A0 cowan@ccil.org
It was impossible to inveigle
Georg Wilhelm Friedrich Hegel=
Into offering the slightest apology
For his Phenomenol= ogy.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 --W. H. Auden, from "People" (1953)
--000000000000c75750057952b9a9--