REPLY: 2:280/464 5dd6ea30
MSGID: 2:280/464.47@fidonet 5dd6fbbc
CHRS: UTF-8 4
TZUTC: 0100
TID: CrashMail II/Linux 1.7
Hallo Wilfred!

 WV> There's also the problem that the squish message base stores date/time
 WV> stamps with a resolution of 2 seconds. That has been causing problems
 WV> in the past where a squish system forwarded messages to its other
 WV> links with the date/times changed from the original, and so causing
 WV> undetected dupes on some systems.

This might be a problem with some tossers, but it's not a problem with the
Squish specification itself. It would surprise me, if Squish didn't use the
original date for rescanned messages.

Quote from the Squish Developers Kit Version 2.00:

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


I suspect hpt from the husky project. In scanarea.c, function makeMsg:

  sc_time((union stamp_combo *) &(xmsg.date_written), (char *)msg->datetime)


 WV> This is of course only a problem if you have more than 1 link to an
 WV> echomail area. Which is never (or shouldn't) be the case for a point
 WV> system. ;)

I'm a node in the othernet ;)

--- GoldED+/LNX 1.1.5-b20180707
 * Origin:  (2:280/464.47)
SEEN-BY: 1/123 15/2 18/200 90/1 103/705 203/0 221/0 227/114 229/354
SEEN-BY: 229/426 452 1014 240/5832 249/206 317 400 280/464 5003 292/854
SEEN-BY: 317/3 322/757 342/200 396/45 423/120 633/280 712/848 770/1
SEEN-BY: 2452/250
PATH: 280/464 229/426