[Moshe]
How about having, in addition to the time-stamp, the size of the file? At least on UNIX, it comes for free with the same stat call.
+1 from me. Note that, besides inter-machine clock skew, some filesystems have a timestamp granularity too coarse to distinguish close-in-time writes. For those (& related) reasons, the attentive Pythoneer will have noted that all of the winning 1st-round Software Carpentry "make"-replacement designs provide for alternatives to timestamps. Tom Tromey's has the clearest discussion of the problems with timestamps: http://software-carpentry.codesourcery.com/entries/build/Tromey/Tromey.html In my industrial experience, (timestamp, size) pairs have never failed in practice. However, "my industrial experience" has been entirely in projects where source-control wrappers add a checkin comment block to every checked-in file, and that alone made it exceedingly unlikely that any two successive versions of a file would have the same size. In Python I'm still (a little) worried about cases like SOME_GLOBAL_CONFIG_OPTION = 0 where "0" gets replaced by "1" or "2" or ... there are lots of interesting things you can do to Python programs without changing their size. At Dragon, checked-in Python files were also subject to the "checkin comment block" rule, so no project under source control suffered from this. I suspect it burned people in their pre-source-controlled development projects, though! One group in particular had a project that involved acres of machine-generated Python modules, and I know they suffered from coarse timestamps on their flavor of Unix (so part of their "make" procedure was to nuke all .pyc's on each build). it's-easy-to-laugh-at-problems-you-don't-have<wink>-ly y'rs - tim