Subj : JS Object save_msg()
To   : deon
From : Digital Man
Date : Wed Dec 18 2024 21:43:11

  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
--- SBBSecho 3.23-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.