Subj : JS Object save_msg() To : deon From : Digital Man Date : Tue Dec 17 2024 22:57:31 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) .