• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: NSFileModificationDate after 2039
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSFileModificationDate after 2039


  • Subject: Re: NSFileModificationDate after 2039
  • From: "Gerriet M. Denkmann" <email@hidden>
  • Date: Tue, 26 Apr 2005 19:22:11 +0200

Some further investigation showed:

TN1150 says "The maximum representable date [of an HFS+ file] is February 6, 2040 at 06:28:15 GMT".
But this cannot be true in a Posix compatible world.


Here we have:
	start of hfs+ time	1904-01-01 00:00:00 +0000	0x00000000
	last of unix time:	2038-01-19 03:14:07 +0000 	0xfc25b07f
	start of unix time: 	1901-12-13 20:45:52 +0000	0xfc25b080
	just before hfs:		1903-12-31 23:59:59 +0000	0xffffffff

That is:
"These dates are stored in unsigned 32-bit integers (UInt32) containing the number of seconds since midnight, January 1, 1904, GMT" (TN1150) - but only for dates between 1904 and 1970 + INT_MAX seconds.


The range 0xfc25b080 ... 0xffffffff is used to store the dates of 1970 + INT_MIN ... 1904.

NSFileManager does the right thing.

The only bugs are:
1. If you use NSFileManager to set a date outside the unix range of 1970 + INT_MIN ... 1970 + INT_MAX you do not get an error, and the date is set to some arbitrarily value. (Probably the start of the legal range).


2. The restriction of NSModificationDate (and of HFS+) to the Unix range of 1970 + INT_MIN ... 1970 + INT_MAX is nowhere documented (although it is kind of natural, once you think of it)

3. utimes() can set microseconds, which are not rounded but ignored.
4. stat() returns nanoseconds, which are always zero.

This is only to be expected, as HFS+ just has a field for seconds. But would be nice to have this mentioned on the respective man pages.

5. No-one seems to have told the Finder (poor thing) that it is now living in a Unix world - it displays the HFS+ value of 0xffffffff as 6. Feb. 2040 6:28 GMT (should be 1903-12-31 23:59:59 +0000) and it treats the HFS+ value of 0x0 as undefined and displays "--".


The NSFileCreationDate (which does not exist in Unix) uses the HFS+ range of 1904 ... February 6, 2040 at 06:28:15 GMT.



But there are other problems:

6. NSFileManager is not prepared to set the NSFileCreationDate to 1970-01-01 00:00:00 +0000.

7. And if the file to be changed resides on another computer it refuses to set NSFileModificationDate or NSFileCreationDate to values before 1970-01-01 00:00:01 +0000. And accepts no NSFileCreationDates after the end of the unix range.



Gerriet.

_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: NSFileModificationDate after 2039
      • From: Chris Ridd <email@hidden>
    • Re: NSFileModificationDate after 2039
      • From: Shawn Erickson <email@hidden>
  • Prev by Date: Re: A Question about [[self superview] doSomething]
  • Next by Date: Re: Binding button.enabled to "NSTextField is not empty"
  • Previous by thread: Re: NSFileModificationDate after 2039
  • Next by thread: Re: NSFileModificationDate after 2039
  • Index(es):
    • Date
    • Thread