Re: NSFileModificationDate after 2039

FROM : Sean McBride
DATE : Mon Apr 25 20:45:18 2005

On 2005-04-25 10:04, Gerriet M. Denkmann said:

>I have a file on HFS+ which has  contentModDate (u_int32_t) =
>0xffffffff.
>This should be: 2040-02-06 07:28:15 +0100.
>(see HFSPlusCatalogFile in /usr/include/hfs/hfs_format.h)
>
>But fileAttributesAtPath:traverseLink: returns:
>NSFileModificationDate = 1904-01-01 00:59:59 +0100;
>
>That is: the NSFileManager reads the unsigned value from HFS+ as a
>signed -1.
>
>Is this a bug, or am I missing something?


I'd say its a bug; file it.  TN1150 says "The maximum representable date
[of an HFS+ file] is February 6, 2040 at 06:28:15 GMT".  That should be
what 0xFFFFFFFF corresponds to.  And NSDate can certainly handle dates
past 2038/2040!

>Also, when I try to set the modification date to any date after
>"2038-01-19 03:14:07 +0000" the date gets replaced with "1904-01-01
>00:00:00 +0000" - but changeFileAttributes: does not return an error.
>
>What is so special about  "2038-01-19 03:14:07 +0000" ? Is this the
>date where the world will end?


joar has explained this.  I'll add that in Classic Mac OS, dates were
"stored in unsigned 32-bit integers (UInt32) containing the number of
seconds since midnight, January 1,  1904, GMT."  (See TN1150)

So i think there are bugs converting to/from Mac 1904-based dates and
unix 1970-based dates.

>HFS+ can do dates up to: "2040-02-06 06:28:15 +0000"  - why does
>NSFileManager refuses to set some dates? Is this documented somewhere?


You might also ask on the Carbon list and/or Darwin list, there are some
HFS experts there.


--
____________________________________________________________
Sean McBride, B. Eng                <email_removed>
Rogue Research                        www.rogue-research.com
Mac Software Developer              Montréal, Québec, Canada