Subj : JS Object save_msg()
To   : Digital Man
From : deon
Date : Sun Dec 22 2024 10:38:58

  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.

If I exported it to another system, it would be exported with the same datetime string and TZUTC string. (No change right?)

In your example, if you lifted and shifted to the east coast, and you are now in EST (UTC-5) and you changed your OS time to be that time zone. Then yes, the message might display as 22 Dec 2024 16:30 EST (or UTC-5:00) now? (Or still show as PST because of when_written_zone?)

If you exported it downstream, it would export with that east coast datetime string, but with a TZUTC string of -0500 right? (It's still the same time though.) (Or could still export as the PST time because of when_written_zone and a -0800 TZUTC?)

If that message then arrived here, it would still be converted back to time_t of 1734759000, but now say 16:30 EST instead of 13:30 PST (or might still show as PST because of above). It still represents to me the correct time it was written (I dont care that you wrote it on the west coast or the east coast, I just like knowing when you wrote it relative to me).

Now, what I was suggesting (or I thought it was doing) with scfg -> Sytem -> Local Time Zone (or a per user instance of Time Zone, when presenting that time_t (1734759000) you could present it in any time zone (and if you were a HAM, you could set it to UTC and everything is in UTC format, or if you were on the east coast but still wanted to see PST, you could set it as such.

IE: when_written_time is UTC, so you just need to convert using that, what's in when_written_zone is not needed here.

You could go a step further, when exporting the message export it in the timezone of scfg -> System -> Local Time Zone (or do it by user), so that the message string is that of the system or user, but the TZUTC is adjusted appropriately - ultimately it should still convert back to time_t 1734759000 (when it was actually written).

I see you've changed when_import_time to now have a bit version of a date :( it'd make that harder to show messages in a per user timezone, since you'd have to write the math functions to achieve the above now(?), instead of a thread safe version of tzset() (I think you have something?) and the OS/strftime doing it?

Your change to when_written_time might affect those playing with the JS (like me), where I'm playing with dates/times for sorting and filtering and also referencing that back to the result of time(). :( I probably dont really have a need to reference them back to time(), but now I cant if I wanted to? EG: Not making a message visable until when_written_time < time().


....лоеп

---
 ю Synchronet ю AnsiTEX bringing back videotex but with ANSI
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.