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

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

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

 NB> JAM, with HPT as the tosser.

i figured that was what it was...

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

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

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

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

 NB> However, I have no idea what method HPT is using, which is why I
 NB> posted about it since something isn't right. Obviously it would be a
 NB> lot worse of a bug if it forwarded messages the same way, but that has
 NB> 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)