TZUTC: -0800   
   MSGID: 53270.sync@1:103/705 2bca729c   
   REPLY: 50217.dove-syncdisc@12:1/2 2bc9d90b   
   PID: Synchronet 3.20a-Win32 master/39b964536 Dec 16 2024 MSC 1916   
   TID: SBBSecho 3.23-Linux master/c33ca5aac Dec 18 2024 GCC 12.2.0   
   COLS: 80   
   BBSID: VERT   
   CHRS: CP437 2   
   NOTE: FSEditor.js v1.105   
     Re: JS Object save_msg()   
     By: deon to Digital Man on Thu Dec 19 2024 07:52 pm   
      
    >  > 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.   
      
   Correct.   
      
    > 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   
      
   0x6763D13C is Thursday, December 19, 2024 7:54:36 AM UTC, which when converted   
   to your system's local time zone (UTC+11:00) is Thu Dec 19 18:54:36 2024. That   
   looks correct. The "UTC+1:00" does *not* impact the displayed date/time, it's   
   just information about the local time zone on the system that created the   
   message. Since these messages were created locally on your system, they should   
   both have your *local* time zone, but the second does not: apparently a   
   misconfiguration on your part.   
      
    > 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).   
      
   No, the expectation is a local time representation of the time_t.   
      
    > 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)?   
      
   No, the expectation is the local time representation of that date/time.   
      
    > 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.   
      
   That's correct.   
      
    > 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).   
      
   No, not what was intended.   
      
    > 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.   
      
   You wouldn't have a local message with a UTC+1:00 time zone value if your   
   configuration was correct. Correct your time zone in SCFG (UTC+11:00) and   
   all's good.   
   --    
                                               digital man (rob)   
      
   Rush quote #57:   
   He picks up scraps of information, he's adept at adaptation .. Digital Man   
   Norco, CA WX: 80.7øF, 13.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs   
   --- SBBSecho 3.23-Linux   
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)   
   SEEN-BY: 10/0 1 102/401 103/1 17 705 105/81 106/201 124/5016 128/187   
   SEEN-BY: 153/7715 218/0 1 215 601 700 840 860 880 226/30 227/114 229/110   
   SEEN-BY: 229/114 206 317 400 426 428 470 550 700 705 266/512 280/464   
   SEEN-BY: 282/1038 291/111 301/1 320/219 322/757 342/200 396/45 460/58   
   SEEN-BY: 633/280 712/848 902/26 5075/35   
   PATH: 103/705 218/700 229/426