Subj : JS Object save_msg()
To : deon
From : Digital Man
Date : Wed Dec 18 2024 09:43 pm
Re: JS Object save_msg()
By: deon to Digital Man on Thu Dec 19 2024 11:12 am
> 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.
But they should normally match (the OS setting and SCFG->Local Time Zone, with regards to offset to UTC). Hence the warning.
> > Nothing's impossible. We could do more to work around a sysop that
> > doesn't use the config wizard and ignores warnings. <shrug> 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.
Some day I'd like the *users* of the BBS to be able to choose the time zone they'd like dates/times to be displayed/entered in, but we're not there yet.
> > 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).
And you fixed that setting, so you're not longer having this problem - right?
> My point is, scfg -> ... -> Local Time Zone shouldnt be used to evaluate
> what time values sync uses to store time_t ints,
It isn't. time_t its always stored in UTC.
> it should be used to
> display the time_t int in a time zone of my choosing.
That's not what "Local Time Zone" means though.
> 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.
Now that you've fixed your configuration, you're good, yeah?
--
digital man (rob)
Steven Wright quote #13:
How do you tell when you're out of invisible ink?
Norco, CA WX: 66.2�F, 22.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs
