Subj : Squish __ftsc_date bug
To   : Kai Richter
From : Oli
Date : Wed Feb 03 2021 12:23:47

Kai wrote (2021-02-02):

 KR> Hello Oli!

 KR> 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.

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

Let's consult the Squish Developers Kit. This stuff is stored in the message header in the .sqd file.

  The  XMSG  structure  has  the following format:
  [...]
  date_written   SCOMBO    164  Date that the message was written.

  date_arrived   SCOMBO    168  Date that the message was placed in
  [...]
  __ftsc_date    char[20]  218  FTS-0001  compatible date.   Squish
                                applications should not access this
                                field directly.  This field is used
                                exclusively by tossers and scanners
                                for  preserving the  original ASCII
                                message date.   Squish applications
                                should  use  the  binary  dates  in
                                date_written  and  date_arrived  to
                                retrieve the message date.

If a message is exported from the Squish message base and has an non-empty __ftsc_date field, the tosser should use the contents of that field for the date. If the message has been created locally (no __ftsc_date), the tosser uses the date_written field. (SCOMBO is DOS datetime)

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

 KR> Isn't the MSGID the solution for that problem?

Yes, MSGIDs is very effective in sort out dupes, but not all messages have a MSGID (see your argument below: old software).

 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?

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

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

hpt does it wrong. I tested it. What else is there to trouble shoot?

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

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

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

not sure this has anything to do with __ftsc_date in the Squish message base.

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

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

It only affects systems that use a Squish database and have downlinks that do a %RESCAN. If it's not fixed it will be there forever. If it were fixed, affected systems could be upgraded to a newer hpt version. Just because some sysops are to lazy to use up-to-date software doesn't mean we shouldn't care about bugs and bug fixing.

It's just a simple bug ...

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

.