Subj : Squish __ftsc_date bug / JAM bug
To   : andrew clarke
From : Oli
Date : Mon Feb 15 2021 13:31:23

andrew wrote (2021-02-15):

 ac> Scott's idea of using his lossy timestamps to recreate XMSG->__ftsc_date
 ac> is nonsense and as you know only has a 50/50 chance of working accurately.

I didn't think he expected it to work accurately, more like it is not relevant to preserve the exact time and 2 second resolution is good enough. The dupe checker in Squish also uses a 2 second granularity.

As a human I really don't care about the seconds, but for machine processing I see no benefits in modifying the time.

 ac> Now, the Squish format stupidly uses those lossy timestamps but there's
 ac> no reason the whole API has to. Conceivably that could be fixed with a
 ac> bit of work so as not to corrupt Squish bases.

Not sure if I understand. What kind of potential corruption do you have in mind?

 ac> In the mean time JAM's msgh->Hdr.DateWritten is a 32-bit unsigned
 ac> integer. (Fortunately being unsigned it will wrap around in 2106, not in
 ac> 2038.)

 ac> The JAM spec says:

 ac> "An ulong representing the number of seconds since midnight, January 1,
 ac> 1970."

 ac> Presumably that's 1970-01-01 00:00 UTC, not local time.

I don't think it's meant to be UTC. From the JAM spec:

  (1) All timestamps created locally (i.e. those not imported from
      other systems) are stored in local time.

The DateWritten field is also used for imported messages. Why should the time ever be converted to UTC? Wouldn't that make everything more complicated? UNIX time in JAM is not a real Unix timestamp, more UNIX-style (UNIXish).

 ac> That value is then fed into mktime() to return the number of seconds
 ac> since 1970-01-01, then a timezone offset is added with gettz().

which seems to be correct behavior.

 ac> But why is gettz() called every time JamWriteMsg() is called? Wouldn't
 ac> that mean HPT adds the local timezone to the DateWritten field every time
 ac> it tosses a message to a JAM base? That's a bug, isn't it? Unless I'm
 ac> reading the code wrong.
[...]

I haven't looked at the code, but wouldn't this already be discovered, if it were a problem?

 ac> api_jam.c also hints at supporting the TZUTC kludge, but it does nothing
 ac> to calculate dates with it. It just stores it as a JAM subfield because
 ac> the spec says it can.

It'd the JAM way. It stores a few important kludges in special fields (like MSGID, REPLY, TZUTC, Via, PATH, SEENBY).

---
 * Origin: . (2:280/464.47)

.