Extract the current entry to the current working directory.
The last modified time of the created file may be adjusted during extraction to compensate for differences in how the .NET Base Class Library deals with daylight saving time (DST) versus how the Windows filesystem deals with daylight saving time. See http://blogs.msdn.com/oldnewthing/archive/2003/10/24/55413.aspx for more context.
In a nutshell: Daylight savings time rules change regularly. In 2007, for example, the inception week of DST changed. In 1977, DST was in place all year round. in 1945, likewise. And so on. Win32 does not attempt to guess which time zone rules were in effect at the time in question. It will render a time as "standard time" and allow the app to change to DST as necessary. .NET makes a different choice.
Compare the output of FileInfo.LastWriteTime.ToString("f") with what you see in the property sheet for a file that was last written to on the other side of the DST transition. For example, suppose the file was last modified on October 17, during DST but DST is not currently in effect. Explorer's file properties reports Thursday, October 17, 2003, 8:45:38 AM, but .NETs FileInfo reports Thursday, October 17, 2003, 9:45 AM.
Win32 says, "Thursday, October 17, 2002 8:45:38 AM PST". Note: Pacific STANDARD Time. Even though October 17 of that year occurred during Pacific Daylight Time, Win32 displays the time as standard time because that's what time it is NOW.
.NET BCL assumes that the current DST rules were in place at the time in question. So, .NET says, "Well, if the rules in effect now were also in effect on October 17, 2003, then that would be daylight time" so it displays "Thursday, October 17, 2003, 9:45 AM PDT" - daylight time.
So .NET gives a value which is more intuitively correct, but is also potentially incorrect, and which is not invertible. Win32 gives a value which is intuitively incorrect, but is strictly correct.
With this adjustment, I add one hour to the tweaked .NET time, if necessary. That is to say, if the time in question had occurred in what the .NET BCL assumed to be DST (an assumption that may be wrong given the constantly changing DST rules).
