Subject: bug#21907: date->string duff ISO 8601 zone format

From: Zefram <[email-masked]>
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