From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Zefram Newsgroups: gmane.lisp.guile.bugs Subject: bug#22033: time-utc format is lossy Date: Mon, 24 Apr 2017 21:32:14 +0100 Message-ID: <20170424203214.GA25444@fysh.org> References: <20151127193825.GA28472@fysh.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1493065997 8693 195.159.176.226 (24 Apr 2017 20:33:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 24 Apr 2017 20:33:17 +0000 (UTC) To: 22033@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane.org@gnu.org Mon Apr 24 22:33:12 2017 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 1d2kfU-00021i-EC for guile-bugs@m.gmane.org; Mon, 24 Apr 2017 22:33:08 +0200 Original-Received: from localhost ([::1]:45793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2kfa-00058c-C3 for guile-bugs@m.gmane.org; Mon, 24 Apr 2017 16:33:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52465) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d2kfR-00058V-Ne for bug-guile@gnu.org; Mon, 24 Apr 2017 16:33:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d2kfO-0004bu-Gn for bug-guile@gnu.org; Mon, 24 Apr 2017 16:33:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:40147) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d2kfO-0004bI-9V for bug-guile@gnu.org; Mon, 24 Apr 2017 16:33:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d2kfO-0003oF-11 for bug-guile@gnu.org; Mon, 24 Apr 2017 16:33:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Zefram Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 24 Apr 2017 20:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22033 X-GNU-PR-Package: guile X-GNU-PR-Keywords: Original-Received: via spool by 22033-submit@debbugs.gnu.org id=B22033.149306594014594 (code B ref 22033); Mon, 24 Apr 2017 20:33:01 +0000 Original-Received: (at 22033) by debbugs.gnu.org; 24 Apr 2017 20:32:20 +0000 Original-Received: from localhost ([127.0.0.1]:38346 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d2keh-0003nJ-KD for submit@debbugs.gnu.org; Mon, 24 Apr 2017 16:32:19 -0400 Original-Received: from river.fysh.org ([87.98.248.19]:42354 ident=Debian-exim) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d2kef-0003nB-Rl for 22033@debbugs.gnu.org; Mon, 24 Apr 2017 16:32:18 -0400 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:To:From:Date; bh=DfIXC++/IjcOmi7ns9G0G63IDodENbDrbEV2gwpRYWQ=; b=YHXRiVq/S2k6miwgj1YRo/zOFtTMZ7bBwfUXtsVhxYkkrTK0BpR+ieuh8FfjQ33rhaWEtf7aOJPliakzVaZa30EO6EC2+vIL3r/Cxv3dhu8H/a4n47D5gN7Lw+4dCTS/nA4sW7pEGBtnRBTAIw8gLWAJuSZU0BL2QgbZk2mXUvA=; Original-Received: from zefram by river.fysh.org with local (Exim 4.84_2 #1 (Debian)) id 1d2kec-0004aV-8h; Mon, 24 Apr 2017 21:32:14 +0100 Content-Disposition: inline In-Reply-To: <20151127193825.GA28472@fysh.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:8785 Archived-At: I wrote: > These two seconds are perfectly >distinct parts of the UTC time scale, and the time-utc format ought to >preserve their distinction. This is a problematic goal. At the time I wrote the bug report I didn't have a satisfactory idea of how to achieve it, but I think I've come up with one now. The essential problem is that the SRFI-19 time structure expects to encapsulate a scalar value -- as it says, a count of seconds since some epoch -- but there is no natural scalar representation of a UTC time. Because of the irregularity imposed by its leaps, the natural representation of a UTC time is a two-part structure, consisting of an integer identifying the day and a fractional count of seconds elapsed within the day. Because UTC days contain differing numbers of seconds, this is a variable-radix system. SRFI-19 doesn't offer any structure that has this simple form. The only structure that it describes as separating representation of the day from time of day is the date structure, which splits up the time representation much more and has the complication of the timezone offset. The present approach of the library is to squeeze a UTC time into the time structure by converting the variable-radix value into a scalar by using a fixed radix of 86400. This has the advantage of producing a scalar, and of the scalar behaving continuously on most UTC days, but the major downside of being lossy, aliasing some UTC times. The scalar also isn't really a count of seconds since an epoch, as SRFI-19 expects, breaking arithmetic on it. It looks rather as though this part of SRFI-19 was written expecting this sort of transformation of UTC, but conflictingly expecting it to serve as an unambiguous encoding and as a genuine count of seconds since an epoch. A simple workaround would be to create a scalar in the same kind of way but using a larger fixed radix: minimally 86401, or more roundly 131072. This means we have a scalar value that fits easily into the time structure, and unambiguously encodes all UTC times. But it's still not a count of seconds since an epoch, and it's appreciably less like such a count because it's no longer continuous across (most) UTC day ends. Since the time structure has separate fields for seconds and nanoseconds, it would be possible to borrow a trick sometimes used with the Unix struct timespec: extending the nanoseconds range to represent leap seconds. This would be mostly like the present arrangement, with the seconds count increasing by 86400 per UTC day, but with a leap second unambiguously represented by the seconds count of the preceding second and a nanoseconds count in the range [1000000000, 2000000000). This fixes the ambiguity, but retains all the other downsides of the present badly-behaved scalar, and adds the substantial downside of breaking expectations of normalisation. The alternative to all of those hacks is to produce a continuous scalar value that genuinely counts the seconds of UTC. This is feasible. It would have a distinct representation for all points on the UTC time scale. By being a true scalar value it would fully meet SRFI-19's description of the time structure, would be represented in normalised fashion, and would support arithmetic operations on the seconds of UTC (fixing bug#26164 with no extra effort). The downside is that this is an unusual and somewhat surprising arrangement. I've never previously seen a linear count of UTC seconds brought out as a product of any time library. It would mean that a time-utc structure is not an encoding of a UTC time as normally understood: the date structure would serve that purpose, and a time-utc would instead have a hybrid meaning halfway between what we usually think of as UTC and TAI times. In the leap-seconds era (1972 onwards), the scalar value in a time-utc would be a constant offset from the scalar value in the corresponding time-tai. This implies that conversion operations would be in a different place from where they are now. Whereas currently date/time-utc conversions are almost purely arithmetical and time-utc/time-tai conversions involve the leap second table, instead date/time-utc conversions would require the leap second table and time-utc/time-tai conversions would be purely arithmetical for the leap-seconds era. (Frequency offsets would come into the time-utc/time-tai conversions, for times in the rubber-seconds era.) I'm pretty sure that this actually-linear treatment of time-utc is not what the author of SRFI-19 envisioned. But it fits the actual words of the standard better than anything else I can imagine, and would fix a bunch of problems that otherwise look painful. I reckon this is the best way forward. What do you think? If you like it, I could work up a patch. -zefram