Subj : JS Object save_msg() To : deon From : Digital Man Date : Wed Dec 18 2024 09:35:37 Re: JS Object save_msg() By: deon to Digital Man on Thu Dec 19 2024 12:58 am > > > Why have a configured timezone at all? > > > Explained above. > > OK, fair enough. I guess I dont understand why a sysop would configure their > OS timezone different to their BBS timezone. 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. > If they didnt have access to the OS configuration, then fair enough, but I > would have thought that was a pretty rare/remote case - and in that case > setting that scfg...Local Time Zone setting could be used to display the > times in that timezone they wanted. 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. > > 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)" > > Personally, I prefer the later. Its pretty absolute, where some folks may > not know what AEDT/ACST/ACDT are. You have that option in SCFG as well, by setting the Time Zone to "Other..." but then you won't get automatic daytime saving time adjustment (if you need that). > Anyway, while the OS might just give you the timezone UTC offset, a quick > parse of /etc/localtime (on linux and mac at least) would give you the > timezone string as well. Dont know if that is at all possible on Win. 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. > Personally I think that's better than a scenario where the time or time_t > value is forced to a timezone that makes the usage of that value untrue. > time_t values are always in UTC (they're not impacted by any timezone setting). The *dispaly* of the time_t value (in numeric or verbal form) can adjust for the local timezone of the reader or the local timezone of the originator or do no adjustment. When Synchronet displays date/time stamps of messages, it displays it in the local time of the originator (which can be UTC), but the underlying time_t value is always in UTC. -- digital man (rob) Synchronet/BBS Terminology Definition #93: UTF-8 = 8-bit Unicode Transformation Format Norco, CA WX: 73.0øF, 21.0% humidity, 2 mph S wind, 0.00 inches rain/24hrs --- SBBSecho 3.23-Linux * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705) .