RS> If a new date/time format can be introduced in a RS> backward-compatible manner, that's how it should be done, IMHO.
That is exactly what my proposal attempts to do. It works within the confines of an already existing string without modification of the structure of the well defined header.
RS> And FidoNet should use an existing standard this time, stop RS> making up new (badly defined) ones.
It isn't badly defined. If you would prefer that strftime-speak was used instead then "%F %T" could replace all the text that spells out each element found in the DateTime definition in fts-0001.016. Spelling it ALL out makes it far more "backwards compatible" in 1995 terms. How much more backwards does one need to go?
Most importantly the four digit year takes care of the much needed bug fix that two digit years are the direct cause of. In my particular case the horror would happen starting on January 1, 2069 which causes a rollback to January 1, 1969.
-={ date --date="01 Jan 69 00:00:00" }=- Wed 01 Jan 1969 12:00:00 AM UTC
whereas;
-={ date --date="2069-01-01 00:00:00" }=- Tue 01 Jan 2069 12:00:00 AM UTC
Big difference and it should be noted that this carries on right through 2099. On other systems it is even worse and the rollovers are reported to be on 20 year cycles, some even less.
For the record today's date in 2120 produces;
-={ date --date="19 Dec 20 20:59:37" }=- Sat 19 Dec 2020 08:59:37 PM UTC
as opposed to;
-={ date --date="2120-12-19 20:59:37" }=- Thu 19 Dec 2120 08:59:37 PM UTC
Note the different days with the four digit year producing the accurate output ... barring any catastrophic even happening that alters the orbit and rotation of the earth as we currently understand it.
Life is good, Maurice
... Ear byþ egle eorla gehwylcun. The grave is a horror to every man. --- GNU bash, version 5.1.0(1)-release (x86_64-motorshed-linux-gnu) * Origin: Little Mikey's Brain - Ladysmith BC, Canada (1:153/7001)
