TZUTC: -0800   
   MSGID: 53258.sync@1:103/705 2bc87865   
   REPLY: 50206.dove-syncdisc@12:1/2 2bc8626c   
   PID: Synchronet 3.20a-Linux master/bbf9d5eac Dec 14 2024 GCC 12.2.0   
   TID: SBBSecho 3.23-Linux master/bbf9d5eac Dec 14 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 Wed Dec 18 2024 05:14 pm   
      
    >   Re: JS Object save_msg()   
    >   By: Digital Man to deon on Tue Dec 17 2024 09:19 pm   
    >   
    > Howdy,   
    >   
    >  >  > OK, it is UTC in there.   
    >   
    >  > Is that intentional?   
    >   
    > No. This is a vanilla, mostly unconfigured, install of Sync (running on my   
    > laptop that I use to build my ansitex shell).   
      
   When you first run SCFG in a fresh install of Synchronet, it should start the   
   configuration wizard which prompts you for the timezone and defaults to the   
   current/best-guess timezone based on your OS configuration. If you skip/abort   
   the config wizard, then yeah, your BBS will be configured to use UTC.   
      
    >  > Synchronet doesn't figure it out, it just uses the timezone you have   
    >  > configured in SCFG->System.   
    >   
    > It figures out the "current time" (from the OS?) to store in the   
    > when_imported_time and when_written_time fields though right? I would have   
    > thought it would be easy to get the timezone from the OS, to populate the   
    > *_zone fields?   
      
   We can automatically get the timezone bias (UTC offset) automatically from the   
   OS, but not the actual timezone name (which is encoded along with the UTC   
   offset in the SMB "when_*_zone" header fields). There are some timezones that   
   share the same UTC offset (some period of the year, or year round), but are   
   not in fact the same timezone.   
      
    >  > timezone don't agree, the Terminal Server logs a warning during startup:   
    >  > "Configured time zone (x, 0xYYYY, offset: z) does not match system-local   
    >  > time zone offset: n"   
    >   
    >  > Are you getting this warning log message?   
    >   
    > Dont know, hadnt looked. With the other stuff the gets spawed out when   
    > starting sync, it doesnt stand out. (I just restarted, and yes its there,   
    > but it doesnt look like a "warning" against all the other informational   
    > messages.)   
      
   If you view the log with a method that highlights warnings (e.g. journalctl)   
   it would stand out.   
      
    >  > You have a mismatch in your configuration. If that's unintentional, then   
    >  > I guess I could make that warning log message an error instead, to   
    >  > hopefully insure that sysops are aware of it in the future. If it's   
    >  > intentional, then I guess I would want to know why and then figure out   
    >  > how to support such a configuration with fewer surprises.   
    >   
    > Can you always get the timezone from the OS?   
      
   Could, yes, but prefer to give the sysop the option to be more specific.   
      
    > Why have a configured timezone at all?   
      
   Explained above.   
      
    > If I want to display everything in a timezone, then sure, that makes   
    > sense (eg: my host is in a VM in country "X", but I am in country "Y"), but   
    > to work out and manipulate dates/times I would have thought you could do   
    > that all based on what the OS returns?   
      
   Your message came here as posted on:   
   "Wed Dec 18 2024 05:14 pm AEDT (30 minutes ago)"   
      
   If we only used "what the OS returns", your message would have been posted on:   
   "Wed Dec 18 2024 05:14 pm +11:00 (30 minutes ago)"   
      
   ... and you can do that (just specify the UTC offset) in SCFG if you prefer,   
   but I prefer the former.   
      
    >  > Are you messing with your system's timezone configuration or TZ   
    >  > environment variable?   
    >   
    > No. Cant imagine a timezone configuration or TZ variable that would still   
    > return +11:00/AEDT but be 12 hrs ago (hence why I used the OS's date command   
    > in the example output to show what the OS's time was).   
      
   I don't really have a ready explanation for why strftime() is doing something   
   you don't expect. At least it's consistent (e.g. between PHP or Python and   
   jsexec)?   
   --    
                                               digital man (rob)   
      
   Breaking Bad quote #25:   
   Now if I could only learn how to lick myself. - Hank Schrader   
   Norco, CA WX: 72.1øF, 18.0% humidity, 5 mph ENE 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 550 700 705 266/512 280/464 282/1038   
   SEEN-BY: 291/111 301/1 320/219 322/757 342/200 396/45 460/58 633/280   
   SEEN-BY: 712/848 902/26 5075/35   
   PATH: 103/705 218/700 229/426