TZUTC: 1100   
   MSGID: 50213.dove-syncdisc@12:1/2 2bc95f0d   
   REPLY: 53261.sync@1:103/705 2bc90df6   
   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:35 am   
      
   Howdy,   
      
    > They shouldn't normally: hence the warning upon startup. But some sysops may   
    > legitimately want to display local times in UTC (big with HAM operators) and   
    > maybe have some good reason why their system/OS is not configured for UTC as   
    > well.   
      
   OK, great, that's what I am suggesting to. Using scfg -> ... -> Local Time   
   Zone, to *display* times in a format of my choosing, regardless of the   
   underlying OS setting.   
      
    > You're suggesting that SCFG display the current date/time (and zone string)   
    > in each timezone that's choosable? That'd be doable, if that's what you're   
    > suggesting.   
      
   Nope, not suggesting that at all. I'm suggesting the first response.   
      
    > Nothing's impossible. We could do more to work around a sysop that doesn't   
    > use the config wizard and ignores warnings.  But I don't see how   
    > that'd help your situation now.   
      
   For me I dont think it needs to a workaround. I would expect SBBS has access   
   to all the system calls to handle mail internally as UTC (as it does), and   
   configuration is used to display it in a timezone of their choosing.   
      
    > time_t values are always in UTC (they're not impacted by any timezone   
      
   I know.   
      
   The problem I am having is this:   
      
   I used save_msg() to post a message, without supplying values to date (and   
   when I did that didnt work as expected either), nor values to the when_*   
   values.   
      
   The system time at the time I called save_msg() was   
   Wed Dec 18 12:32:06 2024 AEDT (or +1100) (which is time_t 1734485526)   
      
   Sync recorded that message as   
   Wed Dec 18 12:32:06 2024 UTC (which is time_t 1734525126)   
      
   And thus, when I promptly read the message, it was "11 hrs from now".   
      
   This is just wrong. And you told me it chose "UTC" because of that setting   
   (scfg -> ... -> Local Time Zone).   
      
   My point is, scfg -> ... -> Local Time Zone shouldnt be used to evaluate what   
   time values sync uses to store time_t ints, it should be used to display the   
   time_t int in a time zone of my choosing.   
      
   I dont believe there is any sysop who would configure their OS to UTC+1100,   
   and purposely configure their BBS to forcefully determine the OS time as UTC   
   (or anything else for that matter). (Which is what that setting is doing in   
   this instance).   
      
   That was probably valid in the DOS days, when DOS didnt know timezones, but   
   these days, it works against you.   
      
      
   ...ëîåï   
      
   ---   
    þ 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