Subj : JS Object save_msg()
To   : deon
From : Digital Man
Date : Fri Dec 20 2024 12:37:51

  Re: JS Object save_msg()
  By: Digital Man to deon on Thu Dec 19 2024 03:42 pm

 >   Re: JS Object save_msg()
 >   By: deon to Digital Man on Thu Dec 19 2024 08:45 pm
 >
 >  > Thus when when scfg -> System ->Local Time Zone equals
 >  > xpTimeZone_Local(), they cancel each other out and age_of_posted_item()
 >  > is truely however many seconds ago the message was stored. (utc minus 660
 >  > plus 660).
 >
 >  > If this is what is intended, then OK, I get it. Why somebody would find
 >  > this useful I guess I dont understand.
 >
 > The time zone offsets are applied to calculate the age of posted messages to
 > account for messages received via message networks: the when_written_time
 > value is a time_t, in UTC, but represents the parsed date/time from the
 > originating message header (which is the local time for the time zone of the
 > poster): it's not necessarily the current UTC time at the time of posting
 > when posted from a different time zone.
 >
 > So yes, the adjustments to calculate the message age look unnecessary when
 > considering only locally posted messages but make sense when considering
 > network-posted messages.

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 04:30 PM, PST
And that's no longer correct. Hrmph.

What we really want to store (and display) is just the current wallclock time at the site of posting. time_t isn't really the right datatype to use for this use case. Some encoding of the ISO-8601 representation of the wallclock time would be more appropriate, and then it wouldn't change when the system/OS time zone is changed. The date/time could be displayed in its UTC or local time zone equivalent (if that was desired), but that's not what most BBS users and sysops want. If someone posted at 4AM in their local time, that's usually what I want to see in the message header.
-- 
                                            digital man (rob)

Steven Wright quote #28:
The hardness of the butter is proportional to the softness of the bread.
Norco, CA WX: 72.9øF, 22.0% humidity, 0 mph SSW wind, 0.00 inches rain/24hrs
--- SBBSecho 3.23-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.