From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#21911: TAI-to-UTC conversion leaps at wrong time Date: Fri, 13 Nov 2015 16:19:58 +0000 Message-ID: <20151113161958.GR13455@fysh.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1447431679 29625 80.91.229.3 (13 Nov 2015 16:21:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 13 Nov 2015 16:21:19 +0000 (UTC) To: 21911@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Fri Nov 13 17:21:12 2015 Return-path: Envelope-to: guile-bugs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZxH67-0003i6-LM for guile-bugs@m.gmane.org; Fri, 13 Nov 2015 17:21:11 +0100 Original-Received: from localhost ([::1]:53881 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH67-00067v-4d for guile-bugs@m.gmane.org; Fri, 13 Nov 2015 11:21:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH60-000646-4I for bug-guile@gnu.org; Fri, 13 Nov 2015 11:21:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxH5z-00077e-8U for bug-guile@gnu.org; Fri, 13 Nov 2015 11:21:04 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47664) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH5z-00077Z-4W for bug-guile@gnu.org; Fri, 13 Nov 2015 11:21:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZxH5y-000059-Mv for bug-guile@gnu.org; Fri, 13 Nov 2015 11:21:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Fri, 13 Nov 2015 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 21911 X-GNU-PR-Package: guile X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.144743163532742 (code B ref -1); Fri, 13 Nov 2015 16:21:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 13 Nov 2015 16:20:35 +0000 Original-Received: from localhost ([127.0.0.1]:37372 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZxH5W-0008W1-Pz for submit@debbugs.gnu.org; Fri, 13 Nov 2015 11:20:35 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:58418) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZxH5B-0008Va-KY for submit@debbugs.gnu.org; Fri, 13 Nov 2015 11:20:32 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxH56-0006tW-DY for submit@debbugs.gnu.org; Fri, 13 Nov 2015 11:20:13 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:59296) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH56-0006tQ-AE for submit@debbugs.gnu.org; Fri, 13 Nov 2015 11:20:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40133) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH52-0004mr-Bl for bug-guile@gnu.org; Fri, 13 Nov 2015 11:20:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZxH51-0006s5-HX for bug-guile@gnu.org; Fri, 13 Nov 2015 11:20:04 -0500 Original-Received: from river6.fysh.org ([2001:41d0:d:20da::2]:39596 helo=river.fysh.org) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZxH51-0006rq-Bj for bug-guile@gnu.org; Fri, 13 Nov 2015 11:20:03 -0500 Original-Received: from zefram by river.fysh.org with local (Exim 4.80 #2 (Debian)) id 1ZxH4x-00050S-0j; Fri, 13 Nov 2015 16:19:59 +0000 Content-Disposition: inline X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x 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-bounces+guile-bugs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.bugs:7902 Archived-At: Probing the TAI-to-UTC conversion offered by srfi-19's time-tai->date, in the minutes around the leap second in 2012: scheme@(guile-user)> (use-modules (srfi srfi-19)) scheme@(guile-user)> (for-each (lambda (d) (write (list d (date->string (time-tai->date (add-duration (julian-day->time-tai 2456109) (make-time time-duration 0 d)) 0) "~4"))) (newline)) (list 43000 43160 43164 43165 43166 43167 43199 43200 43201 43202)) (43000 "2012-06-30T23:56:40Z") (43160 "2012-06-30T23:59:20Z") (43164 "2012-06-30T23:59:24Z") (43165 "2012-06-30T23:59:25Z") (43166 "2012-06-30T23:59:25Z") (43167 "2012-06-30T23:59:26Z") (43199 "2012-06-30T23:59:58Z") (43200 "2012-06-30T23:59:59Z") (43201 "2012-06-30T23:59:60Z") (43202 "2012-07-01T00:00:01Z") The julian-day->time-tai conversion is correct (the JD refers to 2012-06-30T12:00:00 UTC, which is 2012-06-30T12:00:34 TAI), and the duration addition works in a perfectly regular manner in TAI space. All the interesting stuff happens in the TAI-to-UTC conversion, between the time-tai structure and the date structure. The same thing happens if the conversion is performed by separate time-tai->time-utc and time-utc->date calls. The date->string part is correct and uninteresting. The conversion is initially correct, minutes before midnight, but a discontinuity is seen 35 seconds before midnight. Outputs from then up to one second after midnight are one second slow. At one second after midnight it recovers. Because 35 seconds happens to be the TAI-UTC difference prevailing immediately after this leap second, I suspect that this is down to a time_t value (as used in the time-utc structure) for the moment of the leap being misinterpreted as a time-tai seconds value. The UTC-to-TAI conversion is in better shape. As a result, time-tai->time-utc and time-utc->time-tai are not inverses during the 35 second erroneous period. Round-tripping through the two conversions produces an output not matching the input. -zefram