On Monday, November 14, 2016 5:47:36 PM CET Eli Zaretskii wrote: > > Date: Sun, 13 Nov 2016 21:39:32 +0100 > > From: Jernej Simončič <jernej|s-w...@eternallybored.org> > > > > On Sunday, November 13, 2016, 19:53:06, Eli Zaretskii wrote: > > > Does "while DST is in effect" mean that you download the file when DST > > > is in effect, or you examine the timestamp of the file when the DST is > > > in effect? > > > > I download the file when DST is(n't) in effect (I download that > > specific URL quite often, on different computers). > > Then yes, it's a known problem with how the MS-Windows implementation > of the utimes function works: it converts (internally) from local time > to UTC using the current setting of the DST flag, not its setting at > the time being converted. The irony of this is that there should be > no need to go through local time in this case, because the timestamp > provided by Wget is in UTC to begin with, and the low-level Windows > APIs that timestamp files accept UTC values. > > If we care about this, we could have a private implementation of > utimes in mswindows.c, which would DTRT in the use cases needed by > Wget. > > > I just remembered that there may be a 3rd explanation: some msvcrt > > functions return different timestamps depending on whether DST is in > > effect or not - at least with GIMP you can observe that it'll rescan > > all fonts the first time it's run after DST change (I'm not sure if > > this applies only to msvcrt.dll [which MinGW uses by default], or also > > to the runtimes shipped with newer Visual Studio versions). > > You are talking about 'stat', I believe. Yes, they, too, have a > similar bug, but 'stat' is not involved in the code in Wget that sets > the timestamps of downloaded files.
Ah, Eli :-) Just got this mail after sending... Then all please forget my email that I just sent... Regards, Tim
signature.asc
Description: This is a digitally signed message part.
