Godfrey DiGiorgi mused: > > I have certainly not said Mac is perfect. As I said, the Finder's > Inspector and List views are inconsistent, and the reason is the > different code used to interpret the values. I feel the Inspector's '-' > display is more accurate.
Isn't that just about what I said, originally? That both the "-" and the "31 Dec 03" were different ways of saying "I don't know" ? If the List view had also displayed "-" (or "---", like Photoshop) I doubt if the original confusion would have arisen. > However, why should the "0" date case be handled differently based upon > a file system stupidity? Anything that does not put a proper value in > should be handled in the context of the runtime environment's defaults. > That is the expected behavior, as FAT file systems can be read by many > different OSes. Handling it any other way is creating a false > impression that the data input in this field is meaningful. You're the one calling it a file system stupidity. I'm saying it's a deliberate design decision, and it explicitly means "not present". The one thing a file system handler can be certain of, when it writes a file, is the timestamp the file was last modifed. On a FAT file system, that date is the "last written" date, which must be present. As you point out, FAT is used by many different OSes. Not all of those OSes support the concept of more than one file timestamp. In that case they are supposed to use the "last written" field, and to write zeros into the "date created" field. I wouldn't be at all surprised to find that the embedded OS used by Pentax in their DSLRs is such an OS, which is why we see those zero dates. Things get really interesting when you copy a file which has both created and modified dates, anyway. Which, if either, should be updated to reflect the date on which the file was copied? There are arguments to be made for just about any combination you choose.
