The code for the Windows path of "calculateUTCOffset" ignores the return value of GetTimeZoneInformation, and always acts as though the running machine is in the standard time zone. This documentation in <http://msdn.microsoft.com/en-us/library/windows/desktop/ms724421(v=vs.85).aspx> clearly indicates a daylight-savings-time-specific return value that indicates that you should use the "daylight bias" portion of the time zone struct to calculate the correct offset.
<rdar://problem/18559172>
Created attachment 239351 [details] Patch
This bug may be why certain date-related tests are failing depending on user's time zone.
Comment on attachment 239351 [details] Patch r=me It would be nice to get clarity on whether our existing tests cover this, and to add a test to cover this if it's not already covered.
(In reply to comment #4) > (From update of attachment 239351 [details]) > r=me > > It would be nice to get clarity on whether our existing tests cover this, and to add a test to cover this if it's not already covered. We have tests that check for correct calculation of DST-related dates, but we don't have a test that places the test machine in DST or Standard time zones for running the tests. This patch corrects a problem where the local machine state was not being accounted for when computed the time offset compared to UTC. I'll think about this and see if we can come up with a reliable way to toggle this state during test runs.
See also <https://bugs.webkit.org/show_bug.cgi?id=137473> for better testing for this feature.
Comment on attachment 239351 [details] Patch Clearing flags on attachment: 239351 Committed r174377: <http://trac.webkit.org/changeset/174377>
All reviewed patches have been landed. Closing bug.