MSGID: 2:280/464.113 5ca23b8a   
   REPLY: 1:3634/12.73 5ca22d8a   
   Hey mark!   
      
    ml> i don't know where it got changed if it was and isn't just a   
    ml> display anomaly...   
      
   It looks like it didn't get changed although I cannot confirm that.  I'd need   
   to put the node back online to be able to verify that.  The real 'problem' is   
   that the ftn datetime strips the century out of the date and it was originally   
   done here.  Technically you should be seeing that datetime stamp in the   
   msgHeader.   
      
    ml> especially those that only allocate 8 bytes for the serial number   
    ml> portion of the string   
      
   I'd like to see an example.  From what I've observed over the years the MSGID   
   causes more problems when it isn't there than how many nibbles there are in   
   the serial number portion.  Just for fun I thought it would be interesting to   
   see what happens if I piggy-backed a unixtime from the year 2525 on it not   
   unlike a certain nameless software corrupts the address portion of the MSGID.    
   Nothing to worry about since I doubt I'll be around in 2106 and I already have   
   2036 and beyond covered with an 8 nibble unixtime.  As far as the ftn   
   msgHeader datetime, that isn't really an issue until around 2080 or so when   
   stored messages from the +1980's start looking like new postings, probably   
   from the embedded devices you brought up in a previous message.   
      
   Fidonet robots run amock in the 2080's.  :::evil grin:::   
      
   Life is good,   
   Maurice   
      
   ... Don't cry for me I have vi.   
   --- GNU bash, version 5.0.3(1)-release (x86_64-pc-linux-gnu)   
    * Origin: Little Mikey's EuroPoint - Ladysmith BC, Canada (2:280/464.113)   
   SEEN-BY: 15/2 18/200 123/1970 154/10 203/0 221/0 226/17 229/107 354   
   SEEN-BY: 229/426 452 1014 240/5832 249/206 317 400 280/464 5003 310/31   
   SEEN-BY: 317/3 322/757 342/200 393/68 396/45 423/120 633/280 770/1   
   PATH: 280/464 229/426