Subj : JS Object save_msg()
To   : Digital Man
From : deon
Date : Thu Dec 19 2024 11:12:24

  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.

 > 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.

Nope, not suggesting that at all. I'm suggesting the first response.

 > 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.

 > 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).

My point is, scfg -> ... -> Local Time Zone shouldnt be used to evaluate what time values sync uses to store time_t ints, it should be used to display the time_t int in a time zone of my choosing.

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.


....лоеп

---
 ю Synchronet ю AnsiTEX bringing back videotex but with ANSI

.