Hello All,

To further the description of what seems to be happening:

When a PKT arrives here and hpt tosses it, it will forward the PKT to links with the identical times of the messages. However, when HPT stores the message into a JAM message base, it seems to round down to the next even number in seconds of when the message was written, if the message was originally posted with an uneven seconds in the timestamp.

For example:

PKT contains message with 12:06:33

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

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

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20161221
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

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

To further the description of what seems to be happening:

When a PKT arrives here and hpt tosses it, it will forward the PKT to

links

with the identical times of the messages.

that's proper...

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

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

For example:

PKT contains message with 12:06:33

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

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)

Hello mark,

On Thu Dec 22 2016 17:46:54, mark lewis wrote to Nicholas Boel:

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

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

JAM, with HPT as the tosser.

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

That's not what seems to be happening. Since I'm using Linux, I would assume I'm using the Linux "date" format. However, I have no idea what method HPT is using, which is why I posted about it since something isn't right. Obviously it
would be a lot worse of a bug if it forwarded messages the same way, but that has been proven otherwise.

Regards,
Nick

... "Не знаю. Я здесь только работаю."
--- GoldED+/LNX 1.1.5-b20161221
* Origin: thePharcyde_ distribution system (Wisconsin) (1:154/10)

On 2016 Dec 22 23:16:54, you wrote to me:

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

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

JAM, with HPT as the tosser.

i figured that was what it was...

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

That's not what seems to be happening.

it isn't because they're not adding the .5... plus it shouldn't even be being done for JAM or MSG... they dont' do it for MSG so it should also split there and not be done for JAM... just convert it to the proper epoch count and move on... looking at the MKSRCMSG code, they are using the unix epoch since the code explicitly converts from julian dates to unix dates...

Since I'm using Linux, I would assume I'm using the Linux "date"
format.

nope, you can't assume that... the implementation has to be looked at or the comments need to explicitly state it...

However, I have no idea what method HPT is using, which is why I
posted about it since something isn't right. Obviously it would be a
lot worse of a bug if it forwarded messages the same way, but that has been proven otherwise.

yeah, i finally caught all the posts in fidotest... it comes after fidosoft which is why i started answering here, first...


)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin' it wrong...
... The other four seasons: Snow, Mud, Dust and Leaves.
---
* Origin: (1:3634/12.73)