REPLY: 2:280/464.47@fidonet 5dc7d614   
   MSGID: 2:280/464.47@fidonet 5dc7e68a   
   CHRS: UTF-8 4   
   TZUTC: 0100   
   TID: CrashMail II/Linux 1.7   
    AL>> Incidentally, I discovered that the timestamp of that file on   
    AL>> disk was showing as November 25, 1961, so it should be a negative   
    AL>> value. Converting the decimal to hex yields FFFF FFFF F0C4 3650,   
    AL>> which in 2's complement notation is -255576496.  A quick Unix   
    AL>> time conversion results in Sat 25 Nov 1961 10:31:44 PM UTC.   
    AL>> Therefore, it appears that the value is a correct 64-bit Unixtime   
    AL>> for the file timestamp as it was on disk.   
      
    Ol> I polled your system with tcpdump running and sent a .pkt from 1966.   
    Ol> It looks like a binkd bug to me:   
      
    Ol> M_FILE 7eee1e8f.pkt 450 18446744073609551616 0   
    Ol> instead of   
    Ol> M_FILE 7eee1e8f.pkt 450 -100000000 0   
      
   The Binkp/1.0 spec (FTS-1026) says:   
      
       In the basic implementation: size, unixtime and offset   
       MUST be positive numbers or zero.   
      
   What is the "basic implementation"? binkp/1.0 without any OPTs?   
   binkp/1.1 allows a "-1" offset.   
      
   The spec also states:   
       File_size, unixtime and file_offset are decimal integers.   
       Implementation note: mailer MUST check received string to   
       prevent number overflow and skip file if overflow.   
      
   What to do with the situation now? We have one implemenation that sends a   
   negative unixtime and another implementation that returns a timestamp that is   
   584 biliion years in the future.   
      
   I wish a negative unixtime were allowed by the specification in the first   
   place.   
      
   --- GoldED+/LNX 1.1.5-b20180707   
    * Origin: * nigirO (2:280/464.47)   
   SEEN-BY: 1/123 90/1 103/705 154/10 203/0 221/0 227/114 229/101 200   
   SEEN-BY: 229/354 426 1014 240/5832 249/307 317 280/464 5003 5555 292/854   
   SEEN-BY: 310/31 342/200 396/45 423/120 712/848 770/1 2452/250   
   PATH: 280/464 229/426