I've been meditating on the whole os.stat mtime representation thing. Here's a possible alternative approach. * Improve datetime.datetime objects so they support nanosecond resolution, in such a way that it's 100% painless to make them even more precise in the future. * Add support to datetime objects that allows adding and subtracting ints and floats as seconds. This behavior is controllable with a flag on the object--by default this behavior is off. * Support accepting naive datetime.datetime objects in all functions that accept a timestamp in os (utime etc). * Change the result of os.stat to be a custom class rather than a PyStructSequence. Support the sequence protocol on the custom class but mark it PendingDeprecation, to be removed completely in 3.5. (I can't take credit for this idea; MvL suggested it to me once while we were talking about this issue. Now that the os.stat object has named fields, who uses the struct unpacking anymore?) * Add support for setting "stat_float_times=2" (or perhaps "stat_float_times=datetime.datetime" ?) to enable returning st_[acm]time as naive datetime.datetime objects--specifically, ones that allow addition and subtraction of ints and floats. The value would be similar to calling datetime.datetime.fromdatetime() on the current float timestamp, but would preserve all available precision. * Add a new parameter to functions that produce stat-like timestamps to explicitly specify the type of the timestamps (float or datetime), as proposed in PEP 410. I realize datetime objects aren't a drop-in replacement for floats (or ints). In particular their str/repr representations are much more ornate. So I'd expect some breakage. Personally I think the adding/subtracting ints change is a tiny bit smelly--but this is a practicality beating purity thing. I propose making it non-default behavior just to minimize the effects of the change. Similarly, I realize os.stat_float_times was always a bit of a hack, what with it being global state and all. However the approach has the virtue of having worked in the past. I disagree with PEP 410's conclusions about the suitability of datetime as a timestamp object. I think "naive" datetime objects are a perfect fit. Specficially addressing PEP 410's concerns: * I don't propose doing anything about the other functions that have no explicit start time; I'm only proposing changing the functions that deal with timestamps. (Perhaps the right thing for epoch-less times like time.clock would be timedelta? But I think we can table this discussion for now.) * "You can't compare naive and non-naive datetimes." So what? The existing timestamp from os.stat is a float, and you can't compare floats and non-naive datetimes. How is this an issue? Perhaps someone else can propose something even better, //arry/