Subj : JS Object save_msg()
To : deon
From : Digital Man
Date : Sat Dec 21 2024 02:51 pm
Re: JS Object save_msg()
By: deon to Digital Man on Sun Dec 22 2024 09:33 am
> Re: JS Object save_msg()
> By: Digital Man to deon on Sun Dec 22 2024 10:14 am
>
> Howdy,
>
> > > 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.
>
> I'm not following your point.
>
> I'll use an example, and for now pretend we didnt have scfg -> System ->
> Local Time Zone - we just used ctime(), and our OS's are set to our current
> time zone.
>
> If you wrote your message at 22 Dec 2024 13:30 PST (or UTC-8:00), which is
> time_t 1734759000 (on your system). It would display on you system as that,
> and if you exported the mail over the network, it would be exported as 22
> Dec 2024 13:30 (string) with a TZUTC string of -0800.
>
> When that message arrived on my system (UTC+11:00), it would be presented to
> me as the same time (UTC-08:00), and converted to the same time_t
> 1734759000.
No, it would not. The mktime() standard C library function uses *your* local time zone (not mine) in the conversion to time_t. There isn't a standard C runtime library function that takes a broken-down date/time and converts it to a time_t using an arbitrary (user supplied) time zone. The rest of your message
seemed dependant on this first incorrect assumption.
--
digital man (rob)
Steven Wright quote #17:
Ambition is a poor excuse for not having enough sense to be lazy.
Norco, CA WX: 68.8�F, 36.0% humidity, 7 mph W wind, 0.00 inches rain/24hrs
