Hey Ben!   
      
    BR> Yup, looks great from here, dates good and everything!   
      
   Interesting.  Doing the pkt and msg headers exactly the same.   
   The weird thing is that you are replying before it was even sent.   
      
   Stinkin' time zones eh?   
      
   Yeah your date looks okay once it is adjusted to UTC and everything   
   jives.   
      
    BR> {sigh} Date says Aug 02 1992 ... but that last one before this   
    BR> was good!   
      
   Both the local (point) and the remote (Prism BBS) seem to agree   
   about date/times once corrected for UTC in the case of the remote.   
   The date/times from here are already UTC so they never need adjustment.   
   Also they can be corrected to whatever local time since I use 'date   
   +%s' for the id part of MSGID.  I was doing it different before but   
   decided to do it this way so that a sysop anywhere could employ it   
   to use it as a further check using;   
      
     TZ='US/Central' date --date="@$(printf "%d" 0x4e93b315)"   
      
   which will set the robotized UTC's id to your local time.  The original   
   shows up as "Tue Oct 11 03:08:05 UTC 2011" whereas corrected to   
   your timezone shows "Mon Oct 10 22:08:05 CDT 2011" which is 5 hours   
   behind UTC.  For my local time the command becomes;   
      
      TZ='America/Vancouver' date --date="@$(printf "%d" 0x4e93b315)"   
      
   which yeilds "Mon Oct 10 20:08:05 PDT 2011" or 7 hours behind UTC   
   which is correct.  More verification in my favour.  :::evil grin:::   
      
   Neat eh?  UTC is definetly the way to go.  As for the FTN time/dates   
   I cannot explain why you're seeing it any different there than what   
   information is in the headers.  Are you sure they defined the fields   
   correctly?  I've seen people on 32 bit systems define them as ints   
   (32 bit) when the are *REALLY* shorts (16 bit).  The MSG header part   
   is a character string but if the previous PKT header's 16 bit data was   
   defined as ints then all the rest will be out of sync with respect to   
   where things are positioned in the pkt.  Check your source and make   
   sure the definitions are correct.  In the perl call they are shorts   
   or at least the 16 bit variables are which is right as per FTN specs   
   despite that they call them ints which is wrong.   
      
   That is my story and I am sticking to it.   
      
   Life is good,   
   Maurice   
      
   --- GNU bash, version 4.2.10(2)-release (x86_64-core2-linux-gnu)   
    * Origin: Pointy Stick Society (1:261/38.9)