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 22:12:19 -0400 Message-ID: <87o9bckwrl.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 1540865531 19979 195.159.176.226 (30 Oct 2018 02:12:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 30 Oct 2018 02:12:11 +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 Tue Oct 30 03:12: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 1gHJVl-00054j-HD for guile-bugs@m.gmane.org; Tue, 30 Oct 2018 03:12:05 +0100 Original-Received: from localhost ([::1]:50230 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHJXr-0005on-RW for guile-bugs@m.gmane.org; Mon, 29 Oct 2018 22:14:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gHJXl-0005o2-06 for bug-guile@gnu.org; Mon, 29 Oct 2018 22:14:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gHJXg-0001V8-DV for bug-guile@gnu.org; Mon, 29 Oct 2018 22:14:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48312) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gHJXg-0001Uo-3D for bug-guile@gnu.org; Mon, 29 Oct 2018 22:14:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1gHJXf-0001L2-Tl for bug-guile@gnu.org; Mon, 29 Oct 2018 22:14:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Mark H Weaver Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Tue, 30 Oct 2018 02:14:03 +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.15408655954987 (code D ref 22034); Tue, 30 Oct 2018 02:14:03 +0000 Original-Received: (at 22034-done) by debbugs.gnu.org; 30 Oct 2018 02:13:15 +0000 Original-Received: from localhost ([127.0.0.1]:52558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHJWt-0001IM-GG for submit@debbugs.gnu.org; Mon, 29 Oct 2018 22:13:15 -0400 Original-Received: from world.peace.net ([64.112.178.59]:45186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gHJWp-0001I2-VN; Mon, 29 Oct 2018 22:13:14 -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 1gHJWi-0001Dv-8Z; Mon, 29 Oct 2018 22:13:04 -0400 In-Reply-To: (John Cowan's message of "Mon, 29 Oct 2018 20:23:22 -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:9252 Archived-At: Hi John, John Cowan writes: > On Mon, Oct 29, 2018 at 3:17 AM Mark H Weaver wrote: > > Can you please be more concrete and tell me what numbers you think > should be in the second column, to properly reflect the column heading? > I'm not asking for a prose description, but for the actual numbers. > > Here you go: > > +-------------------------------------------------------------------------+ > | TAI seconds UTC seconds Posix seconds | > | since since since | > | midnight TAI midnight UTC midnight UTC | > | 1 Jan 1970 1 Jan 1970 1 Jan 1970 Result of 'time-tai->date' | > |-------------------------------------------------------------------------| > |$2 = ((126230410 126230398 126230398 "1973-12-31T23:59:58Z") | > | (126230411 126230399 126230399 "1973-12-31T23:59:59Z") | > | (126230412 126230400 126230400 "1973-12-31T23:59:60Z") | > | (126230413 126230401 126230400 "1974-01-01T00:00:00Z") | > | (126230414 126230402 126230401 "1974-01-01T00:00:01Z")) | > +-------------------------------------------------------------------------+ Thank you, this is helpful. > So as you see leap seconds are included in both the TAI and the UTC count, > but not in the Posix count. According to , the value of TAI-UTC should change from 12 to 13 at JD 2442048.5, i.e. at midnight UTC on 1 January 1974. The same fact is shown on the graph at the bottom of this page: http://jjy.nict.go.jp/mission/page1-e.html In the values you proposed above, TAI-UTC is 12 uniformly throughout, both before and after the leap second. If you believe that TAI-UTC should not change at JD 2442048.5, then for consistency, you should believe that it doesn't change at JD 2441683.5, the previous leap second one year earlier: --8<---------------cut here---------------start------------->8--- scheme@(guile-user)> ,pp (map (lambda (n) (let* ((tai (make-time time-tai 0 n)) (utc (time-tai->time-utc tai))) (list (time-second tai) (time-second utc) (date->string (time-tai->date tai 0) "~4")))) (iota 5 94694409)) $1 = ((94694409 94694398 "1972-12-31T23:59:58Z") (94694410 94694399 "1972-12-31T23:59:59Z") (94694411 94694400 "1972-12-31T23:59:60Z") (94694412 94694400 "1973-01-01T00:00:00Z") (94694413 94694401 "1973-01-01T00:00:01Z")) --8<---------------cut here---------------end--------------->8--- If we apply the same changes here that you did above, with UTC=Posix at the top and UTC=Posix+1 at the bottom, it would look like this: > +-------------------------------------------------------------------------+ > | TAI seconds UTC seconds Posix seconds | > | since since since | > | midnight TAI midnight UTC midnight UTC | > | 1 Jan 1970 1 Jan 1970 1 Jan 1970 Result of 'time-tai->date' | > |-------------------------------------------------------------------------| > |$2 = ((94694409 94694398 94694398 "1972-12-31T23:59:58Z") | > | (94694410 94694399 94694399 "1972-12-31T23:59:59Z") | > | (94694411 94694400 94694400 "1972-12-31T23:59:60Z") | > | (94694412 94694401 94694400 "1973-01-01T00:00:00Z") | > | (94694413 94694402 94694401 "1973-01-01T00:00:01Z")) | > +-------------------------------------------------------------------------+ Is that a reasonable extrapolation of what you did? Note that in the table above, TAI-UTC is 11 uniformly throughout. This raises of the question of how to combine these two tables into a coherent whole. In order to produce a larger table that includes both of these excerpts and everything in between, TAI-UTC would need to change from 11 to 12 somewhere in the middle. Do you see the problem? Would you like to make another suggestion of what values should go in the second column of these two tables? Thanks, Mark