From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.bugs Subject: bug#22034: time-utc->date shows bogus zone-dependent leap second Date: Mon, 29 Oct 2018 18:33:59 -0400 Message-ID: <87tvl4mlfx.fsf@netris.org> References: <20151127195146.GB28472@fysh.org> <87a7n847o5.fsf@netris.org> <87va5u8q7o.fsf@netris.org> <871s89ajql.fsf@netris.org> <87a7mx8boh.fsf@netris.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1540852487 10767 195.159.176.226 (29 Oct 2018 22:34:47 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 29 Oct 2018 22:34:47 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: zefram@fysh.org, 22034@debbugs.gnu.org, 22034-done@debbugs.gnu.org To: John Cowan Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Oct 29 23:34:42 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 1gHG7M-0002U7-9T for guile-bugs@m.gmane.org; Mon, 29 Oct 2018 23:34:40 +0100 Original-Received: from localhost ([::1]:49377 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHG9N-0002YF-Et for guile-bugs@m.gmane.org; Mon, 29 Oct 2018 18:36:45 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36084) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHG7v-0001XB-Kp for bug-guile@gnu.org; Mon, 29 Oct 2018 18:35:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHG7p-0007Md-8v for bug-guile@gnu.org; Mon, 29 Oct 2018 18:35:14 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48031) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHG7i-0007Jl-Mk for bug-guile@gnu.org; Mon, 29 Oct 2018 18:35:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHG7i-0004NN-E0 for bug-guile@gnu.org; Mon, 29 Oct 2018 18:35:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 29 Oct 2018 22:35: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-submit@debbugs.gnu.org id=B22034.154085249216802 (code B ref 22034); Mon, 29 Oct 2018 22:35:02 +0000 Original-Received: (at 22034) by debbugs.gnu.org; 29 Oct 2018 22:34:52 +0000 Original-Received: from localhost ([127.0.0.1]:52289 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHG7Y-0004Mu-K3 for submit@debbugs.gnu.org; Mon, 29 Oct 2018 18:34:52 -0400 Original-Received: from world.peace.net ([64.112.178.59]:44816) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHG7W-0004MY-9a; Mon, 29 Oct 2018 18:34:50 -0400 Original-Received: from mhw by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1gHG7Q-0008WO-5P; Mon, 29 Oct 2018 18:34:44 -0400 In-Reply-To: <87a7mx8boh.fsf@netris.org> (Mark H. Weaver's message of "Mon, 29 Oct 2018 03:16:19 -0400") 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:9250 Archived-At: Mark H Weaver writes: > John Cowan writes: > >> On Sun, Oct 28, 2018 at 4:40 PM Mark H Weaver wrote: >> >> 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. > > Here's a more detailed display of the same leap second that I chose for > my example, which you quoted above: > > +-----------------------------------------------------------+ > | TAI seconds UTC seconds | > | since since | > | midnight UTC midnight UTC | > | 1 Jan 1970 1 Jan 1970 Result of 'time-tai->date'| > |-----------------------------------------------------------| > |$2 = ((126230410 126230398 "1973-12-31T23:59:58Z") | > | (126230411 126230399 "1973-12-31T23:59:59Z") | > | (126230412 126230400 "1973-12-31T23:59:60Z") | > | (126230413 126230400 "1974-01-01T00:00:00Z") | > | (126230414 126230401 "1974-01-01T00:00:01Z")) | > +-----------------------------------------------------------+ > > The table above illustrates my understanding of the relationship between > "TAI seconds since midnight UTC on 1 Jan 1970", "UTC seconds since > midnight UTC on 1 Jan 1970" and the date object expressed in UTC. See > my previous email for the code to produce the table above using SRFI-19. Sorry, I made a mistake above. Where I wrote: "TAI seconds since midnight UTC on 1 Jan 1970" I should have written: "TAI seconds since midnight TAI on 1 Jan 1970" I'm not aware of any other mistakes in my last message. Given that correction to the heading over the first column, I'd still like to know what numbers you believe should be in a corrected version of the table above. I admit that this is a surprisingly challenging subject, but I think it's important to get to the bottom of this. If there's a deep problem in SRFI-19 regarding its interpretation of UTC seconds, we need to know about it and fix it. This issue affects the entire Scheme community. Thanks, Mark