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).

.