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