Talk:PDB
After checking a few values manually for create/modify/backup times it looks like they're probably seconds-since-1970, rather than seconds-since-1904. Can anyone please confirm which it is?
[edit] seconds in a 32 bit number
As I recall Unix started in December 1969 and will overflow the 32 bit boundary in 2038 or something similar. Starting a 32 bit number in 1904 would overflow already although it is possible to assume an offset I suppose. --DaleDe 13:25, 14 August 2008 (EDT)
An unsigned 32 bit number counts up to 4294967295. Counting in seconds, that's a little over 136 years. So counting from 1st Jan 1904 won't overflow until early in 2040.
Unix time uses a signed integer, so although counting from 1st jan 1970, storing it as a 32-bit number causes overflow in half the time of an unsigned number, and so will overflow sometime in 2038.
The PDB documentation I've found nearly all refers to a start date of 1904. Since PDB and Palm are closely related to Macintosh, which also has a start date of 1904, it seems likely that this is what was originally used.
However, the Perl PDB documentation mentions the Unix start date of 1970. I suspect this is an error in the Perl PDB implementation.
In practical terms, this should not cause a problem for clever interpreters for the following reason:
If the 1904 date has been used, the 32-bit number will be above 0x8000000 for any sensible date for an eBook creation/modification/backup date, as 0x80000000 on unsigned 32-bit 1904 time is around 1972.
If the 1970 date has been used, the 32-bit number will be below 0x80000000 for any sensible date, as since it's a signed date, number 'above' that will be before 1970.
So - if the top bit is set, it must be an unsigned 32-bit, 1904 based date, if the top bit is not set, it must be a signed 32-bit, 1970 based date. --Paul Durrant 15 August 2008
[edit] Time Zone
Are the timestamps UTC, or in the local system time?130.15.24.88 14:17, 28 May 2014 (EDT)
