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