REPLY: 1:3634/12.73 5ce00d91   
   MSGID: 2:280/464.113 5ce02b89   
   CHRS: UTF-8 4   
   Hallo mark!   
      
    ml> export TZUTC=$(date +"%z" | sed 's/\+//')   
      
   Yes but then $TZUTC won't work for normal dating applications as shown by   
   using my FTN date and what would be a corrupted TZUTC since all my systems are   
   set to UTC;   
      
   -={ ':read !date --date="18 May 19  15:58:01 0000"' starts }=-   
   date: invalid date ‘18 May 19  15:58:01 0000’   
   -={ ':read !date --date="18 May 19  15:58:01 0000"' ends }=-   
      
   Without the '+' character (when applicable) produces further error unless   
   compensated for.  Personally I don't trust date/time and tend to just ignore   
   it for the mostpart, especially 2 digit year based ones.  It is simpler - and   
   I believe better - to completely ignore it rather than create a worse bug at   
   the expense of exporting obviously corrupted data.  Also, and more   
   importantly, the TZUTC is part of the msg_body and thus by my recongning   
   shouldn't be tinkered with even it is obviously corrupted such in the case of   
   UTC.  By simply not adding one is the correct answer methinks.  However I'd be   
   receptive to something along this line instead;   
      
     @RFC-3339: 2019-05-18 15:58:01 +0000   
      
   which shows a proper full date without the TZUTC corruption or the English   
   abbreviations which cause even more grief which I won't get into here.  The   
   above kludge can be created using the strftime specifiers +"%F %T %z".  So for   
   coreutils 'date' it could look like this;   
      
     export RFC3339=$(date --date="@${UNIXTIME}" +"%F %T %z")   
      
   Note in the above that $unixtime is the time in seconds when this reply was   
   set in motion = 1558195081 and is used to set the FTN datetime stamp as well.    
   That might be a more useful kludge and could also be set to use nanoseconds   
   for greater uniqueness as follows;   
      
     export UNIXTIME=$(date +"%s.%N")   
      
   My vote would be to supply the unixtime (with or without nanoseconds) and then   
   use that to produce whatever datetime stamp the end user wishes to display the   
   date and time at their end without having to alter the original packed   
   message(s).   
      
   Het leven is goed,   
   Maurice   
      
   ... Huil niet om mij, ik heb vi.   
   --- GNU bash, version 5.0.7(1)-release (x86_64-pc-linux-gnu)   
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)   
   SEEN-BY: 1/123 15/2 18/200 154/10 203/0 221/0 226/17 229/354 426 452   
   SEEN-BY: 229/1014 240/5832 249/206 317 400 280/464 5003 310/31 317/3   
   SEEN-BY: 322/757 342/200 393/68 396/45 423/120 633/280 770/1   
   PATH: 280/464 229/426