AV> how would the software distinguish that from older (legacy) date AV> format?
As proposed it wouldn't. I thought I'd leave that part open to discussion and just go for the gold. This is something that should have happened just over 20 years ago or at least in 2002 when the opportunity presented itself when the 2 digit year was declared obsolete by those in the know.
To be honest I am not aware of anyone who is using abandonware these days so I am not convinced this is really an issue if the much needed change were to actually take place. Do you? It seems to me that this would be a welcome addition all things considered but I do understand it would take some time to impliment. For the software being deployed on this node it is a nobrainer and I could have it up and running in no time. How about you?
AV> The "Date:" kludge containing the date and time in RFC-3339 AV> format with one variation - allow the space between the time and AV> UTC offset. The "datestr" format for that would be "%F %T %:z"
I was adding it as a kludge except with this format; "%F %T %z" which is one byte less than your datestr and does indeed work with every dating routine I threw it at. All use the strftime() function which is available to c, c++, and every half-decent scripting language I can find (perl, python, etc). Even gawk has the strftime() function available to it. This makes it extremely portable to every OS I can think of including Windows.
AV> (try `date '+%F %T %:z'`).
-={ date '+%F %T %:z' }=- 2020-12-19 05:49:41 +00:00
I am partial to;
-={ date '+%F %T %z' }=- 2020-12-19 05:51:23 +0000
which saves a byte and is just as useful. I'll put it as a kludge in my followup msg. Please stay tuned.
Life is good, Maurice
... [Læt] þine lareowas leofe in mode þa þec geornast to gode trymmen.