= Сообщение: 5300 из 7124 ====================================== FTSC_PUBLIC = От : Rob Swindell 1:103/705 18 Dec 20 21:14:04 Кому : Alexey Vissarionov 18 Dec 20 21:14:04 Тема : alternative DateTime (ref: fts-0001.016) FGHI : area://FTSC_PUBLIC?msgid=30754.ftsc_pub@1:103/705+24433a3e На : area://FTSC_PUBLIC?msgid=2:5020/545+5fdd86aa = Кодировка сообщения определена как: ASCII ================================== Ответ: area://FTSC_PUBLIC?msgid=30755.ftsc_pub@1:103/705+24433aed ============================================================================== 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). --- SBBSecho 3.11-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
