15 Feb 21 13:31, you wrote to me:

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

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

But it's necessary to work accurately if you're doing a rescan. That's the whole point of this bug and is probably why Scott had to store the ftsc_date field.

It's been so long since I used the original SquishMail (ie. squish.exe) that I don't recall if rescans were a supported feature.

("squish.exe rescan 3:633/267 fidosoft.husky" maybe?)

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

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

The API just needs to use 2 second resolution for I/O on Squish bases and 1 second resolution everywhere else.

But currently I suspect if you change _stamp in the API to allow 1 second resolution it will break the Squish code.

It will probably also break the ABI if someone is using a DLL version of SMAPI and tries to mix old & new versions, but that situation isn't unique to HPT/SMAPI.

All of that can be ironed out though.

 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,
 ac>> not in 2038.)

 ac>> The JAM spec says:

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

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

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

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

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

You could be right, but at the very least it's ambiguous since AFAIK the convention is for time_t on Linux/BSD be stored as UTC.

But at this point it's really just a matter of throwing mud at the code to see what sticks...

--- GoldED+/BSD 1.1.5-b20180707