We ran into the following conundrum while distributing source code for some open-source software we produce. Our code is pretty straightforward C++ stuff with makefiles designed for GNU make. We distribute the package as a zip archive. Works on most systems (Linux, Windows, MacOS, FreeBSD and others). Now, zip stores and unzip restores the file timestamps. Problem is, if someone downloads the archive in an earlier time zone than the one in which it was produced, the unarchived files have a timestamp in the future. For example, if I create the archive on the east coast and shortly afterwards, someone on the west coast takes it and unpacks it, the files in the archive will have timestamps roughly 3 hours into that person's future because the files were last modified in my timezone (roughly 3 hours ahead of theirs). This confuses make, and the builds fail (in our case, because make's implicit rules do undesired things, although the implicit rules issue could be resolved) because the timestamps of object files it builds are older than the timestamps of the files they're based on (because they're from the future). I tried the -X option to zip, but it doesn't change the file timestamps (both in MacPorts' most recent zip and /usr/bin/zip on MacOS 10.5.8).

How do we work around this problem?

The only things we've found so far is (1) touch all the files after unpacking them or (2) wait 24 hrs before distributing the archive. As far as (1) goes, we don't want to have to tell recipients to do that, because most won't, or probably will miss that portion of the instructions. We've been basically relying on (2), but I'd like to solve this problem in a better way.