Subj : Squish __ftsc_date bug
To   : Oli
From : Kai Richter
Date : Tue Feb 02 2021 22:45:46

Hello Oli!

01 Feb 21, Oli wrote to Kai Richter:

 KR>> say 2 second resolution is the standard and if you have uneven
 KR>> timestamps in your msgbase than that is the bug.

 O> The DOS time format uses a 2 seconds resolution. The creation and
 O> received date is stored has DOS time in the Squish message base.

After export the pkt message does no longer have creation date? As for FTS-0001 it's the last edited date?

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

Isn't the MSGID the solution for that problem?

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

 O> This is what other nodes have reported and I have no reason to doubt
 O> it. Don't you think there are tossers out there which believe that
 O> messages with different time stamps are not the same?

I don't know (out there). I think because of ASCII DateTime would not effect DOS 16-bit file format date stamps it should be ok to see different time stamps as different mails.

I don't doubt that the problem exist but for fault confirmation and trouble shooting it is easier to know the software in use.

 O> doesn't matter, because per Squish specification the __ftsc_date

I will forward you my messy research for the format. In short: For FTS-0001 DateTime is the creation date of the message. A packed message use the last edited date. For type 2 pkt format it's the pkt creation date.

After reading those specs i would recomment msgid for dupe checking. ;-)

 O> should be used on export (rescan). What would be the benefit of not
 O> using the exact time when it's available?

Same like if using: Nothing? Even with a fix available - every hpt system have to use that fix to get rid of the problem. And i think we both know that that is most unlikely to happen.

Regards

Kai

--- GoldED+/LNX 1.1.4.7
 * Origin:  Monobox  (2:240/77)

.