TZUTC: 1100   
   MSGID: 50217.dove-syncdisc@12:1/2 2bc9d90b   
   REPLY: 53267.sync@1:103/705 2bc9b882   
   PID: Synchronet 3.20a-Linux master/7b932f63e Dec  9 2023 GCC 10.2.1   
   TID: SBBSecho 3.23-Linux master/c33ca5aac Dec 18 2024 GCC 12.2.0   
   COLS: 80   
   BBSID: ALTERANT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: JS Object save_msg()   
     By: Digital Man to deon on Wed Dec 18 2024 09:43 pm   
      
   Howdy,   
      
    > Now that you've fixed your configuration, you're good, yeah?   
      
   Yes but...   
      
   Consider these two messages:   
   a) scfg -> System -> Local Time Zone = +11:00   
   index record     152   
   when_written     6763D130 0294 Thu Dec 19 18:54:24 2024 UTC+11:00   
   when_imported    6763D130 0294 Thu Dec 19 18:54:24 2024 UTC+11:00   
      
   b) scfg -> System -> Local Time Zone = +01:00   
   index record     153   
   when_written     6763D13C 003C Thu Dec 19 18:54:36 2024 UTC+1:00   
   when_imported    6763D13C 003C Thu Dec 19 18:54:36 2024 UTC+1:00   
      
   From what I understand:   
   6763D130 is time_t in hex, and 0294 is the offset in hex.   
      
   Thus, time_t 0x6763D130 (1734594864) plus 0x294 (660) does in fact equal   
   Thu Dec 19 18:54:24 2024 UTC+11:00   
      
   However, time_t 0x6763D13C (1734594876) plus 0x3c (60) does *not* equal   
   Thu Dec 19 18:54:36 2024 UTC+1:00   
      
   I looked into your code, and the problem (I think anyway) is in ctime_r   
   (datawrap.c) if the expectation that Sync returns stored times in a UTC string   
   representation (that is then modified by scfg -> System ->Local Time Zone).   
      
   If the expection that sync returns times in "local time" (from ctime_r()),   
   then if you want to present times as per scfg -> System -> Local Time Zone,   
   then the result of ctime() shouldnt be used (for example in smbdump.c#124)?   
      
   While sync is correctly storing time_t as a correct UTC time (for these   
   messages anyway, which where created 12s apart and confirmed above) - when   
   ctime() converts the time_t int back to a string, it is presenting a "local   
   time" string, not a "UTC time" string.   
      
   Thus, calling the return of ctime() as a time in the timezone configured in   
   scfg - System -> Local time Zone - is that what you intended? (which is what   
   ctime() and smb_zonestr() is presenting).   
      
   I hope this makes sense. Ultimately, I dont know why 1734594876+60 should be   
   presented as "Thu Dec 19 18:54:36 2024 UTC+1:00", and further calculations are   
   made from it (generating "10 hrs from now" comments when reading messages)   
   which is simply not true.   
      
      
   ...ëîåï   
      
   ---   
    þ Synchronet þ AnsiTEX bringing back videotex but with ANSI   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10   
   SEEN-BY: 154/30 203/0 218/700 221/0 226/30 227/114 229/110 114 206   
   SEEN-BY: 229/317 400 426 428 550 700 705 240/1120 5832 266/512 280/464   
   SEEN-BY: 280/5003 5006 282/1038 291/111 292/8125 301/1 310/31 320/219   
   SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124   
   SEEN-BY: 467/888 633/280 712/848 770/1 902/26 5020/400 5054/30 5075/35   
   PATH: 103/705 280/464 460/58 229/426