Beman Dawes wrote:

At 06:13 AM 5/8/2003, Peter Dimov wrote: <snip>

...

This is a misunderstanding. Last access time (struct stat::st_atime) and creation time (st_ctime) aren't universal.

Unix's ctime is actually change time, not creation time - it is the time when certain metadata were last changed.

...

Modification time (st_mtime) is common, except on read-only filesystems, which typically only have ctime.

Judging by your "last altered" remark, you mean mtime but call it "last access."

I think that it would be entirely reasonable (and very useful - can avoid reading a file if it hasn't changed since last read) to provide mtime. On read-only filesystems, the creation time should be returned.

You're mixing the concepts of filesystem API and the filesystem on disk. Normally the same filesystem API can be used for any file- system supported by the OS, and file times on an inherently read- only filesystem can appear as modification time and (if the OS supports the notion) as creation or change time.

Yes, I had a similar thought.

What format should be used to report the mtime? I'd prefer to keep the coupling to other Boost libraries low, so I guess that would mean just using std::time_t. That also has the advantage of not promising higher resolution than can actually be delivered by most platforms.

Seems reasonable to me.

What to do if the filesystem doesn't attach any time at all to a file? Fail at compile time? Always return some date in the past, like January 1, 1900, that is impossible as a real mdate (since computers were not invented yet) and so can be relied upon to indicate "no date available"?

Use std::time_t(-1) to be consistent with std::time and std::mktime.