Subj : JS Object save_msg()
To   : deon
From : Digital Man
Date : Thu Dec 19 2024 10:57:10

  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
--- SBBSecho 3.23-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.