GNU logs - #26164, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sat, 18 Mar 2017 22:42:02 +0000
Resent-Message-ID: <handler.26164.B.148987690115425 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 26164 <at> debbugs.gnu.org
Date: Sat, 18 Mar 2017 22:41:26 +0000
From: Zefram <zefram@HIDDEN>
Message-ID: <20170318224126.GK6518@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Zefram <zefram@HIDDEN>
Subject: bug#26164: Acknowledgement (time-difference mishandles leap seconds)
Message-ID: <handler.26164.B.148987690115425.ack <at> debbugs.gnu.org>
References: <20170318224126.GK6518@HIDDEN>
X-Gnu-PR-Message: ack 26164
X-Gnu-PR-Package: guile
Reply-To: 26164 <at> debbugs.gnu.org
Date: Sat, 18 Mar 2017 22:42:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 26164 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
26164: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D26164
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-guile@HIDDEN:

Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Andy Wingo <wingo@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 19 Apr 2017 14:33:02 +0000
Resent-Message-ID: <handler.26164.B26164.14926123636695 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Zefram <zefram@HIDDEN>
Cc: 26164 <at> debbugs.gnu.org
From: Andy Wingo <wingo@HIDDEN>
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
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-guile@HIDDEN:

Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 19 Apr 2017 16:23:02 +0000
Resent-Message-ID: <handler.26164.B26164.149261892817951 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 26164 <at> debbugs.gnu.org
Date: Wed, 19 Apr 2017 17:22:03 +0100
From: Zefram <zefram@HIDDEN>
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>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

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

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Sun, 21 Oct 2018 22:58:02 +0000
Resent-Message-ID: <handler.26164.B26164.154016263727050 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26164
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Zefram <zefram@HIDDEN>
Cc: 26164 <at> debbugs.gnu.org
Received: via spool by 26164-submit <at> debbugs.gnu.org id=B26164.154016263727050
          (code B ref 26164); Sun, 21 Oct 2018 22:58:02 +0000
Received: (at 26164) by debbugs.gnu.org; 21 Oct 2018 22:57:17 +0000
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>
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-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

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Zefram <zefram@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 05 Nov 2018 11:03:01 +0000
Resent-Message-ID: <handler.26164.B26164.154141576312977 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26164
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Mark H Weaver <mhw@HIDDEN>
Cc: 26164 <at> debbugs.gnu.org
Received: via spool by 26164-submit <at> debbugs.gnu.org id=B26164.154141576312977
          (code B ref 26164); Mon, 05 Nov 2018 11:03:01 +0000
Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 11:02:43 +0000
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>
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-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

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: John Cowan <cowan@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 05 Nov 2018 13:49:01 +0000
Resent-Message-ID: <handler.26164.B26164.15414256873784 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26164
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: zefram@HIDDEN
Cc: Mark H Weaver <mhw@HIDDEN>, 26164 <at> debbugs.gnu.org
Received: via spool by 26164-submit <at> debbugs.gnu.org id=B26164.15414256873784
          (code B ref 26164); Mon, 05 Nov 2018 13:49:01 +0000
Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 13:48:07 +0000
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>
Content-Type: multipart/alternative; boundary="000000000000f856720579eb21ce"
X-Spam-Score: 0.0 (/)
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 &lt;<a href=3D"mailto:zefr=
am@HIDDEN">zefram@HIDDEN</a>&gt; 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&#39;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">&gt;Having said all of this, I should admit that I&#39;m n=
ot an expert on time<br>
&gt;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--

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Mon, 05 Nov 2018 20:48:02 +0000
Resent-Message-ID: <handler.26164.B26164.154145083610851 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26164
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Zefram <zefram@HIDDEN>
Cc: 26164 <at> debbugs.gnu.org
Received: via spool by 26164-submit <at> debbugs.gnu.org id=B26164.154145083610851
          (code B ref 26164); Mon, 05 Nov 2018 20:48:02 +0000
Received: (at 26164) by debbugs.gnu.org; 5 Nov 2018 20:47:16 +0000
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>
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-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

Message sent to bug-guile@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#26164: time-difference mishandles leap seconds
Resent-From: Mark H Weaver <mhw@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Tue, 06 Nov 2018 00:14:01 +0000
Resent-Message-ID: <handler.26164.B26164.15414632225572 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 26164
X-GNU-PR-Package: guile
X-GNU-PR-Keywords: 
To: Zefram <zefram@HIDDEN>
Cc: 26164 <at> debbugs.gnu.org
Received: via spool by 26164-submit <at> debbugs.gnu.org id=B26164.15414632225572
          (code B ref 26164); Tue, 06 Nov 2018 00:14:01 +0000
Received: (at 26164) by debbugs.gnu.org; 6 Nov 2018 00:13:42 +0000
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>
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-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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.