Subj : alternative DateTime (ref: fts-0001.016)
To : Alexey Vissarionov
From : Rob Swindell
Date : Fri Dec 18 2020 09:14 pm
Re: alternative DateTime (ref: fts-0001.016)
By: Alexey Vissarionov to Maurice Kinal on Sat Dec 19 2020 06:48 am
> Good ${greeting_time}, Maurice!
>
> 18 Dec 2020 06:36:54, you wrote to Andrew Leary:
>
> MK> proposed DateTime = a string 19 bytes long.
> MK> Format = "YYYY-MM-DD hh:mm:ss" where,
> MK> YYYY = four digit year
> MK> MM = two digit month ranging from 01 to 12
> MK> DD = two digit day ranging from 01 to 31
> MK> hh = two digit hour ranging from 00 to 23
> MK> mm = two digit minute ranging from 00 to 59
> MK> ss = two digit second ranging from 00 to 59
> MK> Since there is no room for the UTC offset DateTime should be set to
> MK> UTC in order to avoid confusion. This format will ensure that the
> MK> packed message is exactly the same byte length as specified in
> MK> fts-0001.016 not counting the ASCII null charater that terminates the
> MK> string as per packed MSG header specification for all header strings
> MK> (eg To, From, subj, etc).
>
> I've only one question: how would the software distinguish that from older
> (legacy) date format?
That may be possible for *newer* software to make sense of multiple formats, including a new one, but there's option for *older* software to recognize a new format. There in lies the rub.
> Even if we want everyone migrating to the new software, there should be some
> transition period, while we _must_ (as in FTA-1006) maintain compatibility.
I think that transition period, for FidoNet, is: forever. :-)
> Given that, here's my proposal.
>
> The "Date:" kludge containing the date and time in RFC-3339 format with one
> variation - allow the space between the time and UTC offset. The "datestr"
> format for that would be "%F %T %:z" (try `date '+%F %T %:z'`).
>
> Rules:
> 0. The "Date:" kludge _must_ contain valid time in either "%F %T %:z" or "%F
> %T%:z" format.
> 1. Once the "Date:" kludge is present in a received message, the compatible
> software (that's aware of the "Date:" kludge) _must_ use the time from the
> kludge.
> 2. When composing a message, the compatible software _must_ fill the "Date:"
> kludge and _should_ fill the legacy header with the valid time (considering
> precision limitation) or it _may_ fill the legacy header with all zero
> bytes.
"all zero bytes" is not a backwards compatible date value, most likely causing the packet to be discarded as corrupted or just really old, by existing or old FidoNet software. I would mandate that the FTS-1 date field be set as defined in FTS-1.
> This would allow us to get rid of ancient software without breakind almost
> everything.
>
> Also, the example of the "Date:" kludge can be found in this my message :-)
I didn't see a "Date:" kludge in your message (I looked).
