TID: FMail-lnx64 2.1.0.18-B20170815
RFC-X-No-Archive: Yes
TZUTC: 0100
CHRS: UTF-8 2
PID: GED+LNX 1.1.5-b20161221
MSGID: 2:280/464 5fbcf692
REPLY: 1:153/7001 5fbc4389
Hi Maurice,

On 2020-11-23 23:19:37, you wrote to me:

 MK> @MSGID: 1:153/7001 5fbc4389
 MK> @REPLY: 2:280/464 5fbc09bf
 MK> @CHRS: UTF-8 4

 MK> @UTC_OFFSET: 0000
 MK> -={ Corrected datetime: 2020-11-23 19:12:14 +0000 }=-

Those are non standard. And the 'TZUTC: -0800' is missing. Now if there is
fido software that sorts messsages chronologically, it can't do it correctly.

 MK> I think I have come up with a routine that corrects the msg datetime
 MK> stamp relative to the user's perspective that also compensates for the
 MK> corrupted TZUTC offset.  The above corrected datetime was generated
 MK> from the msg I am replying to.  The output's format in
 MK> strftime()-speak is "%F %T %z" and can easily be adjusted to the
 MK> enduser's preference.  I don't believe it would be wise to output it
 MK> to a flag given it is to the enduser's configuration rather than
 MK> fidonet at large.

 MK> What a hassel.  Personally I don't see it being worth the effort but
 MK> all things considered I believe the above corrected datetime stamp, or
 MK> something like it, would be an appropriate replacement for the ftn msg
 MK> header's datetime stamp and should have happened roughly 18 years ago.


Bye, Wilfred.

--- FMail-lnx64 2.1.0.18-B20170815
 * Origin: FMail development HQ (2:280/464)
SEEN-BY: 1/123 18/200 90/1 105/81 120/340 123/131 124/5016 154/10
SEEN-BY: 203/0 221/0 226/30 227/114 229/101 424 426 452 664 1016 240/5832
SEEN-BY: 249/110 206 317 400 280/464 5003 288/100 292/8125 310/31
SEEN-BY: 317/3 322/757 342/200 396/45 423/120 460/58 633/280 770/1
PATH: 280/464 229/101 426