GNU bug report logs - #21907
date->string duff ISO 8601 zone format

Previous Next

To reply to this bug, email your comments to 21907 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: bug-guile <at> gnu.org
Subject: date->string duff ISO 8601 zone format
Date: Fri, 13 Nov 2015 14:59:13 +0000

scheme@(guile-user)> (use-modules (srfi srfi-19))
scheme@(guile-user)> (date->string (julian-day->date 2450000 3600) "~4")
$1 = "1995-10-09T13:00:00+0100"
scheme@(guile-user)> (date->string (julian-day->date 2450000 3630) "~4")
$2 = "1995-10-09T13:00:30+0100"

There are two problems here with date->string's representation of zone
offsets for the ISO 8601 formats "~2" and "~4".  Firstly, because the
time-of-day is represented in the extended format with colon separators,
the zone offset must also be represented with colon separators.  So the
first "+0100" above should be "+01:00".

Secondly, the offset is being truncated to an integral minute, so the
output doesn't fully represent the zone offset.  More importantly,
because the local time-of-day isn't being adjusted to match, it's not
accurately representing the point in time.  ISO 8601 doesn't permit
a seconds component in the zone offset, so you have a choice of three
not-entirely-satisfactory options.  Firstly, you could round the zone
offset and adjust the represented local time accordingly, so the 3630
conversion above would yield either "1995-10-09T13:00:00+01:00" or
"1995-10-09T13:01:00+01:01".  Secondly, you could use the obvious
extension of the ISO 8601 format to a seconds component, outputting
"1995-10-09T13:00:30+01:00:30".  Or finally you could signal an error
when trying to represent a zone offset that's not an integral minute.

Incidentally, for offsets of -1 to -59 inclusive, the truncation isn't
clearing the negative sign, so is producing the invalid output "-0000".
The zero offset is required to be represented with a "+" sign.  If you
take the rounding option described above, anything that rounds to a
zero-minutes offset must yield "+00:00" in the output.

-zefram

Message #8 received at 21907 <at> debbugs.gnu.org (full text, mbox):

From: Zefram <zefram <at> fysh.org>
To: 21907 <at> debbugs.gnu.org
Subject: Re: bug#21907: date->string duff ISO 8601 zone format
Date: Wed, 19 Apr 2017 22:21:46 +0100

[Message part 1 (text/plain, inline)]

A sequence of two patches is attached.  The first fixes the ~2/~4 bug,
signalling an error for any unrepresentable offset.

The second is a bonus patch, which fixes related problems in ~z, the
RFC 822 zone format specifier.  Prior to the patch, ~z outputs "Z" for
UT, which would be correct for ISO 8601 format but is deprecated (along
with all the other single-letter syntax) for RFC 822.  The patch changes
that to the approved "+0000".  ~z also had exactly the same problems as
~2/~4 regarding unrepresentable offsets, so the patch fixes them in the
same way.

I could report the ~z problems in a separate ticket if you like.
Beware that the second of these patches has some textual dependence on
the first, so trying to handle them separately might just be confusing.

-zefram

[0001-fix-SRFI-19-s-ISO-8601-zone-output-formats.patch (text/x-diff, attachment)]

[0002-fix-SRFI-19-s-RFC-822-zone-output-format.patch (text/x-diff, attachment)]

Previous Next

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