Subj : JS Object save_msg()
To : deon
From : Digital Man
Date : Sat Dec 21 2024 02:14 am
Re: JS Object save_msg()
By: deon to Digital Man on Sat Dec 21 2024 07:26 pm
> Re: JS Object save_msg()
> By: Digital Man to deon on Fri Dec 20 2024 12:37 pm
>
> Howdy,
>
> > Looking/thinking more about the use of time_t for storage of date/time
> > for posted messages because your questions (thank you for those), I do
> > see a flaw, after all these years: If the system (OS) time zone is
> > changed (beyond just annual daylight versus standard time changes), then
> > the stored "when_written_time" values in message headers no longer
> > actually reflect the "wallclock time" of the posted message, as was the
> > intent.
>
> > For example, I post/save a message right now and it reflects (correctly):
> > Dec-20-2024 12:30 PM, PST and it stores the current time_t value that
> > represents that (as can be seen with ctime, etc.).
>
> > However, if I move to BBS to the U.S. east coast and change the system
> > (OS) time zone setting that message is now reported as having been posted
> > at: Dec-20-2024 03:30 PM, PST
>
> Actually, I was pleased to see that messages are stored in time_t, and in
> fact the "wall time" you mention is still valid? I think its the right
> approach, because it doesnt represent that actual time a message was written
> (on your system anyway).
>
> IE: You posting a message at 12:30pm PST, isnt that 3:30pm on the east
> coast? Its that PST (aka scfg -> system -> local time zone) setting that is
> messing things. (I think - because that text is appended to the ctime()
> results.)
That's how messages are sent over message networks though, the date/time stamp in the message header is the *local* time at site of the posting.
> If that was removed, (or rather changed to control how time is *displayed*
> only), and then reading messages can still be displayed in PST (if that is
> what you wanted), or shown "local" time zone (EST? dont know what east cost
> timezone is called).
A sysop can remove the time zone portion of the message header display if they prefer, but I like it. If a message is posted at 4AM EST, I want to see that when I read the message (not 12AM PST).
> (Additionally, it should be easier to allow users to show times in "their"
> local time - if it wasnt PST/EST, or for that matter AEDT/+11:00 then you
> use the users preferred timezone, instead of the system one when rendering a
> date.)
>
> IE: Messages, as written as stored in utc (time_t), no change there.
Message networks don't send date as time_t values, they send local wallclock time. Converting that wallclock time to time_t (e.g. using mktime) uses the current system/OS time zone for the conversion.
> When displaying a message, you set the timezone accordingly, then use
> ctime()? (Dont know the c/c++ function to display time in a differnet
> timezone, but I know it is manipulated by TZ environment variable right?
You can't set the TZ environment variable dynamically for a single thread, so no, that's not really feasible. You have to apply the UTC offset yourself (which I do now for the UTC-related @-codes).
> Showing age (which I do like in Sync), its easy to figure out how many hours
> ago something was posted, by using time_t (utc ints).
>
> > If someone posted at 4AM in their local
> > time, that's usually what I want to see in the message header.
>
> That I agree. Hence why I actually like the time offset appended to the time
> (+11:00 in my case). When I see a message as ... 04:00:00 +06:00, and its
> 6pm for me, I know immediately that it was written at 9am my time, and thus
> 9 hrs ago. But I do agree the timezone string looks good too, just harder to
> the math.
That's why Synchronet does the math for you. :-)
--
digital man (rob)
Rush quote #12:
Hiding beneath the sheets, got to try and fill the void...
Norco, CA WX: 55.6�F, 70.0% humidity, 0 mph ENE wind, 0.00 inches rain/24hrs
