After an off-list discussion with Victor I have decided to reject PEP 410. Here are my reasons for rejecting the PEP. (Someone please copy this to the PEP or reference this message in the archives on mail.python.org.) 1. I have a general dislike of APIs that take a flag parameter which modifies the return type. But I also don't like having to add variants that return Decimal for over a dozen API functions (stat(), fstat(), etc.). I really think that this PEP would add a lot of complexity that we don't need. 2. The Decimal type is somewhat awkward to use; it doesn't mix with floats, there's a context that sets things like precision and rounding, it's still a floating point type that may lose precision (something which many people don't get when they first see it). 3. There are *very* few clocks in existance (if any) that actually measure time with more than 56 bits of accuracy. Sure, for short time periods we can measure nanoseconds. But a Python (64-bit) float can represent quite a large number of nanoseconds exactly (many millions of seconds), so if you're using some kind of real-time timer that reset e.g. at the start of the current process you should be fine using a float to represent the time with great precision and accuracy. On the other hand, if you're measuring the time of day expressed in seconds (and fractions) since 1/1/1970, you should consider yourself lucky if your clock is accurate within 1 second. (Especially since POSIX systems aren't allowed to admit the existence of leap seconds in their timestamps -- around a leap second you must adjust your clock, either gradually or abruptly.) I'll give you that some people might have clocks accurate to a microsecond. Such timestamps can be represented exactly as floats (at least until some point in the very distant future, when hopefully we'll have 128-bit floats). 4. I don't expect that timestamps with even greater precision than nanoseconds will ever become fashionable. Given that light travels about 30 cm in a nanosecond, there's not much use for more accurate time measurements in daily life. Given relativity theory, at such a timescale simultaneity of events is iffy at best. 5. I see only one real use case for nanosecond precision: faithful copying of the mtime/atime recorded by filesystems, in cases where the filesystem (like e.g. ext4) records these times with nanosecond precision. Even if such timestamps can't be trusted to be accurate, converting them to floats and back loses precision, and verification using tools not written in Python will flag the difference. But for this specific use case a much simpler set of API changes will suffice; only os.stat() and os.utime() need to change slightly (and variants of os.stat() like os.fstat()). 6. If you worry about systems where float has fewer bits: I don't think there are any relevant systems that have both a smaller float type and nanosecond clocks. So far the rejection note. As to the changes alluded to in #5: Let os.stat() and friends return extra fields st_atime_ns (etc.) that give the timestamps in nanoseconds as a Python (long) integer, such that e.g. (in close approximation) st_atime == st_atime_ns * 1e-9. Let os.utime() take an optional keyword argument ns=(atime_ns, mtime_ns). Details of the actual design of this API, such as the actual field and parameter names, may change; this is just a suggestion. We don't need a PEP for this proposal; we can just open a tracker issue and hash out the details during the code review. I'm also in favor of getting rid of os.stat_float_times(). As proposed in another thread, we may deprecated it in 3.3 and delete it in 3.5. I'm not excited about adding more precision to datetime and timedelta. -- --Guido van Rossum (python.org/~guido)