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