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 03: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 ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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

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

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.


...ëîåï

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

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 ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

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

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
---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: JS Object save_msg()
By: deon to Digital Man on Sun Dec 22 2024 09:33 am

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

No, it doesn't. The JS when_written_time property is still a time_t representation - I do the conversion (encoding upon assignemnt, decoding upon use) to the SMB date storage automatically for you.
--
digital man (rob)

Synchronet/BBS Terminology Definition #73:
SMB = Synchronet Message Base (e.g. smblib)
Norco, CA WX: 62.3øF, 48.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

Re: JS Object save_msg()
By: deon to Digital Man on Sun Dec 22 2024 09:33 am

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?

I'd have to do that conversion anyway (before or after my recent change), but at least now the starting date/time (before any conversion) won't change based on the current local system/OS time zone configuration. So, no, not harder now than before if/when I want to convert message dates to user-supplied time zone.
--
digital man (rob)

Rush quote #80:
He knows changes aren't permanent, but change is .. Tom Sawyer
Norco, CA WX: 62.3øF, 48.0% humidity, 3 mph WNW wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net

A sysop can remove the time zone portion of the message header display if

hey

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

I like that also. It may seem trivial, but it reminds me that we are
carrying on conversations with folks who are not from our area of the world and, in fact, might be quite distant from us.


* SLMR 2.1a * Procrastination Day Has Been Postponed!
---
þ Synchronet þ CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP

Re: JS Object save_msg()
By: Digital Man to deon on Sat Dec 21 2024 02:51 pm

Howdy,

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.

Oh, that was a bad assumption on my part. I did think when_import_time was a valid time_t value. (IE: The utc time the message was written.)

I wanted to check it out, so I set up my test system to UTC-8:00, and exported a messages to FTN to clrghouz, then into Alterant (UTC+11:00), and indeed, on my test system:

when_written 6764CEAC FE20 Thu Dec 19 17:55:56 2024 UTC-8:00

Is a valid time_t for the printed time, and on alterant

when_written 6763C37C FE20 Thu Dec 19 17:55:56 2024 UTC-8:00

it is not.

Incidently, the time_t on alterant 1734591356, is exactly 19hrs incorrect, which just so happens to be the difference in our timezones.


...ëîåï

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

Re: JS Object save_msg()
By: Digital Man to deon on Sat Dec 21 2024 04:59 pm

Howdy,

No, it doesn't. The JS when_written_time property is still a time_t representation - I do the conversion (encoding upon assignemnt, decoding upon use) to the SMB date storage automatically for you.

Actually I was refering to the post implementation of your changes to when_written_time - from your commit example:

Here's an example from smbutil v of a message header posted after this change:
when_written 03292595 41E0 Fri Dec 20 18:22:21 2024 PST

0x03292595 (53028245) is the now new value of when_written_time right? and time() will return a number like 1734898576, which will always be less.

But I think I get you, when I read a when_written_time, it'll convert back to time_t value like time()?


...ëîåï

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

Re: JS Object save_msg()
By: deon to Digital Man on Mon Dec 23 2024 07:20 am

Re: JS Object save_msg()
By: Digital Man to deon on Sat Dec 21 2024 04:59 pm

Howdy,

No, it doesn't. The JS when_written_time property is still a time_t representation - I do the conversion (encoding upon assignemnt, decoding upon use) to the SMB date storage automatically for you.

Actually I was refering to the post implementation of your changes to when_written_time - from your commit example:

Here's an example from smbutil v of a message header posted after this change:
when_written 03292595 41E0 Fri Dec 20 18:22:21 2024 PST

0x03292595 (53028245) is the now new value of when_written_time right?

Not exactly. That's the value/format stored in msghdr_t.when_written.time (for newly added/posted messages only), but the JS message header property 'when_written_time' is still always in time_t format.

But I think I get you, when I read a when_written_time, it'll convert back to time_t value like time()?

Correct. It's a transparent change for JS scripts/programmers.
--
digital man (rob)

Sling Blade quote #7:
Karl: I don't reckon the Good Lord would send anybody like you to Hades.
Norco, CA WX: 68.1øF, 37.0% humidity, 0 mph ESE wind, 0.00 inches rain/24hrs ---
þ Synchronet þ Vertrauen þ Home of Synchronet þ [vert/cvs/bbs].synchro.net