C. Make st_mtime a floating point number. This won't offer nanosecond resolution, as C doubles are not dense enough.
This is the most Pythonic approach.
-1
This then locks Python into a specific bit-description notion of a double in order to get the appropriate number of significant digits to describe time sufficiently. Embedded/portable processors may not support the notion of an IEEE double.
In addition, timers get increasingly dense as computers get faster. Thus, doubles may work for nanoseconds, but will not be sufficient for picoseconds.
If the goal is a field which never has to be changed to support any amount of time, the value should be "infinite precision". At that point, a Python Long used in some tuple representation of fixed-point arithmetic springs to mind. ie. (<long>, <bit of fractional point>)
I'm sorry, but I really don't see the point of wanting to record file mtimes all the way up to nanosecond precision. What would it mean? Most clocks are off by a few seconds at least anyway. Python has represented time as Pythin floats (implemented as C doubles) all its life long and it has served us well. --Guido van Rossum (home page: http://www.python.org/~guido/)