Subj : JS Object save_msg()
To : deon
From : Digital Man
Date : Thu Dec 19 2024 10:57 am
Re: JS Object save_msg()
By: deon to Digital Man on Thu Dec 19 2024 07:52 pm
> > Now that you've fixed your configuration, you're good, yeah?
>
> Yes but...
>
> Consider these two messages:
> a) scfg -> System -> Local Time Zone = +11:00
> index record 152
> when_written 6763D130 0294 Thu Dec 19 18:54:24 2024 UTC+11:00
> when_imported 6763D130 0294 Thu Dec 19 18:54:24 2024 UTC+11:00
>
> b) scfg -> System -> Local Time Zone = +01:00
> index record 153
> when_written 6763D13C 003C Thu Dec 19 18:54:36 2024 UTC+1:00
> when_imported 6763D13C 003C Thu Dec 19 18:54:36 2024 UTC+1:00
>
> From what I understand:
> 6763D130 is time_t in hex, and 0294 is the offset in hex.
Correct.
> Thus, time_t 0x6763D130 (1734594864) plus 0x294 (660) does in fact equal
> Thu Dec 19 18:54:24 2024 UTC+11:00
>
> However, time_t 0x6763D13C (1734594876) plus 0x3c (60) does *not* equal
> Thu Dec 19 18:54:36 2024 UTC+1:00
0x6763D13C is Thursday, December 19, 2024 7:54:36 AM UTC, which when converted to your system's local time zone (UTC+11:00) is Thu Dec 19 18:54:36 2024. That looks correct. The "UTC+1:00" does *not* impact the displayed date/time, it's just information about the local time zone on the system that created the message. Since these messages were created locally on your system, they should both have your *local* time zone, but the second does not: apparently a misconfiguration on your part.
> I looked into your code, and the problem (I think anyway) is in ctime_r
> (datawrap.c) if the expectation that Sync returns stored times in a UTC
> string representation (that is then modified by scfg -> System ->Local Time
> Zone).
No, the expectation is a local time representation of the time_t.
> If the expection that sync returns times in "local time" (from ctime_r()),
> then if you want to present times as per scfg -> System -> Local Time Zone,
> then the result of ctime() shouldnt be used (for example in smbdump.c#124)?
No, the expectation is the local time representation of that date/time.
> While sync is correctly storing time_t as a correct UTC time (for these
> messages anyway, which where created 12s apart and confirmed above) - when
> ctime() converts the time_t int back to a string, it is presenting a "local
> time" string, not a "UTC time" string.
That's correct.
> Thus, calling the return of ctime() as a time in the timezone configured in
> scfg - System -> Local time Zone - is that what you intended? (which is what
> ctime() and smb_zonestr() is presenting).
No, not what was intended.
> I hope this makes sense. Ultimately, I dont know why 1734594876+60 should be
> presented as "Thu Dec 19 18:54:36 2024 UTC+1:00", and further calculations
> are made from it (generating "10 hrs from now" comments when reading
> messages) which is simply not true.
You wouldn't have a local message with a UTC+1:00 time zone value if your configuration was correct. Correct your time zone in SCFG (UTC+11:00) and all's good.
--
digital man (rob)
Rush quote #57:
He picks up scraps of information, he's adept at adaptation .. Digital Man
Norco, CA WX: 80.7�F, 13.0% humidity, 1 mph ESE wind, 0.00 inches rain/24hrs
---
� Synchronet � Vertrauen � Home of Synchronet � [vert/cvs/bbs].synchro.net
