Subj : Squish __ftsc_date bug
To   : Kai Richter
From : Oli
Date : Mon Feb 01 2021 18:01:40

Kai wrote (2021-02-01):

 O>> When messages are %RESCANed hpt doesn't use the __ftsc_date field
 O>> from the Squish message base, but the 2-second precision DOS date.
 O>> Which means some messages (~50%) are exported with the time one
 O>> second off.

 KR> I've never seen uneven timestamps in my editor. Hell, at the moment of
 KR> writing i see 12:43:49 in the header on the from/to lines. But after
 KR> saving the mail it switched to 12:43:48, lucky me. ;-)

Your messages are dupe save ;).

 KR> As far as i remember squish does have a 2 seconds resolution. But i don't
 KR> know why. If i do not see further than my nose i would say 2 second
 KR> resolution is the standard and if you have uneven timestamps in your
 KR> msgbase than that is the bug.

The DOS time format uses a 2 seconds resolution. The creation and received date is stored has DOS time in the Squish message base. Usually you don't see any uneven times in your message editor, but in Golded you can hit I and look at the hexdump of the message header. There you should see the original date in ASCII (only in a Squish base, JAM is different). It's stored in a field called __ftsc_date.

 O>> Some tosser's dupe checkers might fail ...

 KR> Is this speculation/theory or could you name a real issue?

This is what other nodes have reported and I have no reason to doubt it. Don't you think there are tossers out there which believe that messages with different time stamps are not the same? But it really doesn't matter, because per Squish specification the __ftsc_date should be used on export (rescan). What would be the benefit of not using the exact time when it's available? (hpt does store the original time in __ftsc_date, it just ignores it on export).

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

.