22 Dec 16 12:03, you wrote to All:

 NB> To further the description of what seems to be happening:

 NB> When a PKT arrives here and hpt tosses it, it will forward the PKT to links
 NB> with the identical times of the messages.

that's proper...

 NB> However, when HPT stores the message into a JAM message base, it seems
 NB> to round down to the next even number in seconds of when the message
 NB> was written, if the message was originally posted with an uneven
 NB> seconds in the timestamp.

ewwww... what message base format are we talking about?

 NB> For example:

 NB> PKT contains message with 12:06:33

 NB> HPT will store the message in the JAM message base with 12:06:32 as the
 NB> time it was written.

 NB> HPT will forward the message to links with the original time, 12:06:33.

yeah, it shouldn't do that... it should round /up/ to the next even second
if the code is following the m$ DOS time stamp format documentation...

int(round((time.sec / 2) + .5)

that says (or should say) take the seconds (time.sec), divide it by 2
(using real number division instead of integer division), add .5, round
that result and finally then take the integer value by effectively lopping
off the decimals... adding the .5 effectively means you'll always round
up...

this may be a relic from the SQUish base... it has the DOS file system 2sec
granularity i described in my recent post on the original topic... HPT is
probably using the same time routine and stuffing everything into a JAM
base instead of having different routines per supported message base...
here's the information on the datetime stamp in the SQUish base format...

===== snip squish.txt =====
The  SCOMBO type is used for  describing a message date/time stamp. This
structure has the following format:

          Name      Type      Ofs  Description
          date      word      0    DOS bitmapped date value.  This field is
                                   used to store a message date.

                                   The first five bits represent the day of
                                   the month.  (A value of 1 represents the
                                   first of the month.)

                                   The next four bits indicate the month of
                                   the year. (1=January; 12=December.)

                                   The  remaining  seven bits  indicate the
                                   year (relative to 1980).

          time      word      2    DOS  bitmapped time  value.   This field
                                   used to store a message time.

                                   The first five bits indicate the seconds
                                   value,  divided by  two.   This  implies
                                   that all  message  dates and  times  get
                                   rounded  to a  multiple of  two seconds.
                                   (0  seconds  = 0;  16  seconds  = 8;  58
                                   seconds = 29.)

                                   The next six  bits represent the minutes
                                   value.

                                   The  remaining  five bits  represent the
                                   hour value, using a 24-hour clock.

Total: 4 bytes
===== snip squish.txt =====

it is exactly the DOS FAT12/FAT16/FAT32 time stamp format... look at the
second paragraph on the time section and recall my previous post (to
wilfred) about the 5bits used for the storage of the seconds...

the fix would be to not convert the time stamp to the DOS file system time
format when writing to JAM and MSG formats... in JAM the time stamps are
unsigned 32bit integers (ulong) according to the original JAMLIB C code...
in 16bit pascal code, this is a longint which is signed so has only half
the count that the unsigned C ulong has... in JAM the number is the seconds
since the epoch...

the question then is which epoch... 1970 or 1980... the unix epoch is 1970
Jan 1... the DOS epoch (used for IBM BIOS INT 1Ah, DOS, OS/2, FAT12, FAT16,
FAT32 and exFAT filesystems) is 1980 Jan 1...

i don't recall which came first, MAPI or SMAPI... one was SQUish only...
the other was derived from the SQUish only one and had JAM and MSG grafted
in... i suspect that grafting is using the same time conversion routine for
all three formats... i have not gone looking into the code to be sure,
though... empirical evidence seems to indicate this, though... in fact, a
quick running through my JAM bases on this point, using HPT and GoldEd+,
shows all seconds are even numbers... looking on my main system, using
fastecho and TimED, shows odd and even seconds...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin'
it wrong...
... Technically horrible stuff, but somehow very tasty.
---