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.
---
 * Origin:  (1:3634/12.73)