[Webkit-unassigned] [Bug 106750] String(new Date(2010, 10, 1)) is wrong in KRAT, YAKT

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=106750





--- Comment #5 from Gavin Barraclough <barraclough at apple.com>  2013-05-27 19:49:28 PST ---
Okay, the last two issues are closely related, and also ultimately rise from the 2038 problem.

In determining the local time offset, we separately calculate the offset from UTC to local standard time, and from standard time to DST.  We check for the DST offset being non-zero to indicate daylight saving being in affect.

The code does the "+= secondsPerDay" because in calculating the offset from standard to DST it sloppily just calculates the difference in hours/minutes/seconds – ignoring days/months/years, and assumes that if the clock has moved backwards that is because we've rolled around past midnight.  This is probably usually true, but makes the code pretty fragile.

Since UTC calculation is not dependent on finding an "equivalent year" we always use the current year (assuming, as the spec does, that UTC offset for a given timezone never changes – which is of course wrong).  Since the DST offset should also be calculated using current data these should always be in sync – however the 2038 bug means that for years from 2010 we can't find an equivalent year, so we'll stick with the historic data.  This means we can end up using a mix of current (UTC) and historic (DST) data.

In 2010 KRAT summertime was at +8, and standard time was at +7.  Since mid 2011 standard time has been at +8 (and there has been no DST).  Comparing these values, we see the summer of 2010 as being standard time since +8 == +8 (whereas in reality it was DST), and the period that should be standard time we treat as being DST with an offset of -1 (resulting in the YAKT/YAKST timezone names being backwards).  The DST offset of -1 trips over the fragile "+= secondsPerDay", and gets converted into a DST offset of +23.

The really crazy thing here is that we basically don't need to be doing any of this.  We're calculating the UTC-to-standard and standard-to-DST offsets separately, but they're always just added together to calculated the offset from UTC to local time – we just need to know this combined offset, and whether DST is in force at a given time.  But (on most systems) we can just get these values straight from localtime_r  – much of the work done to calculate these values is completely unnecessary.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.