I have no idea how zip stores time information and especially timezone information, but I haven't had this kind of issue with other projects that released their source via zip. The issue should just go away if there has been sufficient time elapsed between the zip times and local times. Maybe there is an alternative solution?

drh added on 2009-08-13 13:03:20:
This is a limitation of the ZIP file format. There is no provision in ZIP for a "timezone" field. There is only a date and time field (in the old MSDOS format). Fossil inserts the date and time as UTC. If the program that unpacks the ZIP archive interprets the time in the local timezone, then the time can be off by several hours.

I cannot think of a reasonable workaround. Can anybody else suggest something?

anonymous claiming to be bch added on 2009-08-13 16:40:17:
Timestamp UTC minus 1 whole day? A note could be included either as a link-through page, or beside the 'download zip' link to indicate archives are back-dated to accommodate build-systems (i.e. make (http://en.wikipedia.org/wiki/GNU_make#Modern_versions) and the limitations of zip datestamping.

-bch

anonymous claiming to be tsbg added on 2009-08-14 20:38:47:
Adding a "Extended Timestamp Extra Field" could solve this problem. The specification of this field can be found on the Info-Zip web page http://www.info-zip.org/doc/ in the file appnote-iz-latest.zip.

-- tsbg

drh added on 2009-08-15 02:18:47:
Thanks for suggesting the "extended timestamp" addition and for a pointer to where to find documentation about it. That fixed the problem. See check-in 90048e0b30f12377b33110b279f19299643fe830,