This sounds like the good old Windows being one hour off problems. curl stores the file normally (with what I believe is the correct timestamp from the remote server) and it uses the OS function calls to retrieve the time and date of the file in the subsequent request. If that then gets the wrong time due to DST or whatever, I don't think curl can do a whole lot about it. It uses the time the OS tells it.

the file was last modified. "Last-Modified" (GMT) returned by MS IIS server was calculated correctly

Which calculation was correct do you mean? Are you saying it set the correct file stamp on the saved file?

Curl should keep and use full history of DST on/off dates for each time zone to handle DST for the files created years ago.

No. curl asks the operating system for the file's timestamp.

This article proposes to use GetFileInformationByHandle() instead of stat() on Windows: http://search.cpan.org/~shay/Win32-UTCFileTime-1.58/lib/Win32/UTCFileTime.pm#BACKGROUND_REFERENCE

tool_operate.c contains the function setfiletime() with special code for Windows. It seems that we need a getfiletime() too.

As a "workaround", compile curl with a recent version of Visual C++, because stat() has been fixed in Visual C++ 2013: https://msdn.microsoft.com/en-us/library/bb531344.aspx

Oh, right, thanks for pointing that out. Now it all comes back to me.

For me personally I'm fine with recommending people with going >= MSVC 2013 (since they're available as no-cost downloads from Microsoft), but I also won't object if someone wants to go ahead and implement a getfiletime() function that works on other/earlier windows compilers.

Fixed, thanks for reporting!