On 2016 Dec 23 11:58:30, you wrote to me:

 ml>> what i recall is that some software uses the DOS time stamp that the
 ml>> file system uses... that time stamp has 2 second resolution... DOS
 ml>> FAT12, FAT16 and FAT32 time stamps are packed 16-bit values... only
 ml>> bits 0 to 4 are used to count the seconds. you can't count to 59 with
 ml>> only 5 bits unless you cut the resolution in half... thus you get 2
 ml>> second resolution...

 WV> Yes, I know about that. And hpt probably uses something like that for
 WV> the internal date/time representattion before it stores it in the JAM
 WV> messagebase. Otherwise I can't explain why that even happens in Nick's
 WV> native linux environment...

remember there are two message format libraries... one based on SQUish and
the other also based on SQUish but with JAM and MSG added in... MAPI and
SMAPI?? and then there's the original JAMLIB released by joho and crew...

but the origin based on SQU is why some utils of HPT still show their SQU
roots (eg: sqpack)... SQUish uses that old DOS file system time format with
2sec granularity... i suspect they're using the same routine with JAM
instead of branching off for the date at the same place they do for MSG
which we know uses a string format... the JAM one is just a plain unix time
stamp and needs no manipulation...

)\/(ark

Always Mount a Scratch Monkey
Do you manage your own servers? If you are not running an IDS/IPS yer doin'
it wrong...
... I'm being held prisoner in a chocolate factory. Don't send help.
---