OK beat you to it... I'ts 1.30am :)
I'm at home now, but was able to run a quick test and it seems the problem is indeed solved with attached exe.
I had read something about windows using "Gregorian" times since 1601 for files (why ?!?) 
but too tired to fully digest your explanation at the time (and had to "test" some wine too)
What's the downside of G_W? is it with regards to sharing while handle is open etc?
Anyways thanks for all your hard work.
Off to sleep.

On 25/01/07, Shachar Shemesh <shachar@shemesh.biz> wrote:
Julian Pace Ross wrote:
> Modified: 25 July 2005, 14:52:08
> Modified: 25 July 2005, 14:52:08
> Modified: 25 July 2005, 15:52:08
So it's past midnight here, and I had to make sure some wine used by my
GF for cooking is good, so I don't have time to track down the precise
meaning of this problem. Broadly speaking, however, it goes something
like this:
Windows suck.

More specifically, while FILETIME is DEFINED to be the number of
100-nanoseconds since January 1st, 1601, and time_t is defined to be the
number of seconds since January 1st, 1970, merely converting between the
two based on this information simply doesn't produce correct file times
when the date falls inside a daylight saving zone.

It seems that while file times are stored in some form of UTC, this is
only approximately UTC, as it still shifts by an hour when going
into/out of daylight saving.

Unfortunately, I could not find, under the circumstances mentioned
above, any good way of finding out whether a specific date is or is not
daylight saving, which means that our "ft2ut" (FILETIME to Unix time_t)
function is off by 1 hour for certain date ranges. There does not appear
to be any sane way of solving this problem.

So, instead, I decided to ignore the problem altogether. Instead of
correctly converting a FILETIME to time_t, I'm converting it
incorrectly, but using the precise opposite function, I manage to
convert it back to the original FILETIME. This means that I'm now
setting the file's time using the Win32 SetFileTime, instead of using
the POSIX "utimes".

Quite expectedly, there is a downside. SetFileTime will only set times
over files through their file handle. In other words, in order to set
the file's time, I now need to open it with GENERIC_WRITE access. This
is very far from being ideal, but I suspect it's what Window's
implementation of "utimes" does anyways.

As far as I can tell, under my current condition, the bug is now solved.
Attached is our, now famous, zia file with 1.02test2, as well as the
patch file from 1.01 (i.e. - not incremental to the previous patch posted).

Any feedback most welcome.