Email list hosting service & mailing list manager

Dates and times John Cowan (03 Dec 2019 17:08 UTC)
Re: Dates and times Lassi Kortela (03 Dec 2019 17:20 UTC)
Re: Dates and times Lassi Kortela (03 Dec 2019 17:27 UTC)
Re: Dates and times John Cowan (03 Dec 2019 19:03 UTC)
Re: Dates and times Lassi Kortela (03 Dec 2019 20:00 UTC)
(missing)
Re: Dates and times Lassi Kortela (14 Dec 2019 13:36 UTC)

Re: Dates and times Lassi Kortela 14 Dec 2019 13:36 UTC

>>     Is it OK to demand the use of "T" as the separator character between
>>     date and time? ISO 8601 also accepts a space.
>>
>>     What about time zones? For parsing it's useful to rely on UTC, but for
>>     display to humans a local time is easier. Do you know how widespread
>>     the library support is for parsing local times if the UTC offset is
>>     stated at the end of the timestamp?

> Yes, requiring T should be fine. RFC 3339 (a profile of ISO 8601)
> requires it.  I think parsing time offset (not timezone) data is common
> as well.  The RFC also provides a convention of "-00:00" to mean
> "unknown offset"; I don't know how common support for that is, but it
> probably falls back to UTC in all cases.

Changing the separator to 'T', I got used to it surprisingly soon. It
should be fine.

I'll clarify the SRFI to use RFC 3339 format for all dates, and give
example date(1) and strftime() commands to generate the most useful
variants:

1996-12-19
1996-12-19T16:39:57Z
1996-12-19T16:39:57-08:00

Thanks for making the case for RFC 3339.