"ISO 8601" nitpick (was: Re: Again on feeds in Gemini format)

[Rohan Kumar]

On Thu, Nov 19, 2020 at 03:51:43PM -0800, Nathan Galt wrote:
>> On Nov 19, 2020, at 7:44 AM, Solderpunk <solderpunk at posteo.net> 
>> wrote:
>>
>> I would argue strongly in favour of
>> supporting only a single format, namely the ISO 8601 format (in which
>> today is 2020-11-19).
>
>You mean like 2020-11-19T23:48:17Z? Maybe including milliseconds, too?  
>Or maybe something like 2020-11-19T15:49:57-0800?
>
>I remember seeing a list of "ISO 8601" formats that this one newsreader 
>had to deal with. The list of formats was about a dozen elements long.

It might be a better idea to use RFC 3339, a profile of the ISO 8601 
date format.  See https://tools.ietf.org/html/rfc3339.
It was also mentioned in the Wikipedia article for ISO 8601: 
https://en.wikipedia.org/wiki/ISO_8601. Its main difference, according 
to section 5.6 of the spec:

>NOTE: ISO 8601 defines date and time separated by "T".
>Applications using this syntax may choose, for the sake of
>readability, to specify a full-date and full-time separated by
>(say) a space character.

It also has a provision for unknown local offsets:

>If the time in UTC is known, but the offset to local time is unknown,
>this can be represented with an offset of "-00:00".  This differs
>semantically from an offset of "Z" or "+00:00", which imply that UTC
>is the preferred reference point for the specified time.  RFC2822
>[IMAIL-UPDATE] describes a similar convention for email.

If you aren't familiar with either format but you have GNU date 
installed, you can give them both a spin. For ISO 8601:

	date -I{date,hours,minutes,seconds,ns}

For RFC 3339:

	date --rfc-3339={date,seconds,ns}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 898 bytes
Desc: not available
URL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20201119/7659be57/attachment.sig>