TZUTC: -0800
MSGID: 53267.sync@1:103/705 2bc9b882
REPLY: 50213.dove-syncdisc@12:1/2 2bc95f0d
PID: Synchronet 3.20a-Linux master/bbf9d5eac Dec 14 2024 GCC 12.2.0
TID: SBBSecho 3.23-Linux master/c33ca5aac Dec 18 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 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. 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)
SEEN-BY: 103/705 105/81 106/201 124/5016 128/187 153/757 7715 154/10
SEEN-BY: 154/30 203/0 218/700 221/0 226/30 227/114 229/110 114 206
SEEN-BY: 229/317 400 426 428 550 700 705 240/1120 5832 266/512 280/464
SEEN-BY: 280/5003 5006 282/1038 291/111 292/8125 301/1 310/31 320/219
SEEN-BY: 322/757 341/66 234 342/200 396/45 423/120 460/58 256 1124
SEEN-BY: 467/888 633/280 712/848 770/1 902/26 5020/400 5054/30 5075/35
PATH: 103/705 280/464 460/58 229/426
|
