Closed Bug 630428 Opened 13 years ago Closed 13 years ago

Update WinXP slaves for 2007 daylight savings time changes (ecma/Date/15.9.5.8.js tests failing on XP)

Categories

(Release Engineering :: General, defect, P2)

Product:
Release Engineering
Component:
General
Platform:
x86
Windows XP
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: philor, Assigned: coop)

References

(
URL
)

Details

(Keywords: intermittent-failure, Whiteboard: [orange:time-bomb] See comment 8)

Attachments

(1 file)

Install the appropriate Windows update to get the required DST fixes
2.53 KB, patch
armenzg
: review+
coop
: checked-in+
Details | Diff | Splinter Review 
No idea whose bug it is, or whether it was that one hour only on January 31st, or only January 31st 2011, or every end of month and we just haven't seen ends of months on Windows XP tinderboxes with runs from 15:00 to 16:00, or what.

http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1296517114.1296517913.4948.gz
Rev3 WINNT 5.1 tracemonkey opt test jsreftest on 2011/01/31 15:38:34
s: talos-r3-xp-014

REFTEST TEST-UNEXPECTED-FAIL | file:///C:/talos-slave/test/build/jsreftest/tests/jsreftest.html?test=ecma/Date/15.9.5.8.js | (new Date(1301643806118)).getMonth() wrong value  item 9
REFTEST TEST-UNEXPECTED-FAIL | file:///C:/talos-slave/test/build/jsreftest/tests/jsreftest.html?test=ecma/Date/15.9.5.8.js | (new Date(1320133406118)).getMonth() wrong value  item 44

and http://tinderbox.mozilla.org/showlog.cgi?log=TraceMonkey/1296515712.1296516431.28980.gz and http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1296515057.1296515790.25751.gz, those being the only three that ran during that hour.
Item 9 from comment 0 (3:47pm - (-8h) = 11:47pm) falls in the same range as items 6 - 8 from comment 1 (11:45pm).

I guess these boxes don't have the new daylight saving rules, so e.g. Jan 31 11:30pm PST + (31 + 28) * msPerDay = Mar 31 11:30pm PST under the old rules, while it's Apr 1 12:30am PST under the new rules, leading to different answers for .getMonth().

Same for items 41 - 44, where Jan 31 11:30pm PST + (31 + 28 + 31 + ...) comes out to Oct 31 11:30pm PST under the old rules and Nov 1 12:30am PST under the new rules.

Though I'm not sure why we wouldn't have seen this on e.g. 2010-12-31 11:30pm PST.
I think the XP boxes weren't running at all then; I know they weren't unhidden until 2011-01-06.
Could we try running something like javascript:alert((new Date(1301643000000)).toDateString()) on these XP boxes and see whether it comes up Mar 31 or Apr 1, and get the timezone patch installed if needed?
Assignee: general → nobody
Component: JavaScript Engine → Infrastructure
Product: Core → Testing
QA Contact: general → infra
Component: Infrastructure → Release Engineering
Product: Testing → mozilla.org
QA Contact: infra → release
Summary: ecma/Date/15.9.5.8.js | (new Date(1301641687034)).getMonth() wrong value item 9 and | ecma/Date/15.9.5.8.js | (new Date(1320131287034)).getMonth() wrong value item 44 between 15:00 and 16:00 on the 31st (of January, at least) on WinXP → Update WinXP slaves for 2007 daylight savings time changes
Version: Trunk → other
Will this be solved by bug 593118 (upgrade xp slaves to sp3) ?
http://support.microsoft.com/kb/946480 seems to suggest so.  If so, I'd dup forward since this bug has more information.
Adding a dependency on that bug.
Depends on: 593118
Summary: Update WinXP slaves for 2007 daylight savings time changes → Update WinXP slaves for 2007 daylight savings time changes (ecma/Date/15.9.5.8.js tests failing on XP)
Does this mean we are going to hit this problem every end of the month? or every daylight saving changes? and which one are those?

I guess the related fixes are:
http://support.microsoft.com/kb/933811
http://support.microsoft.com/kb/933812
In theory it's whenever one of [31, 59, 90, 120, 151, 181, 212, 243, 273, 304, 334, 365].map(#(v) v*24*60*60*1000) added to the current date results in either April 1st or November 1st, between midnight and 1 am.

The next days are

 "2011-02-28", "2011-03-02", "2011-04-01", "2011-04-02",
 "2011-05-02", "2011-05-03", "2011-06-01", "2011-06-02",
 "2011-07-02", "2011-07-03", "2011-08-01", "2011-08-02",
 "2011-09-01", "2011-09-02", "2011-09-30", "2011-10-02",
 "2011-11-01", "2011-12-02"

during the 3pm-4pm and 11pm-12am time slots.

Hrm, just remembered there's also the test that adds TZ_ADJUST, so add to that the 7am-8am time slot the day after.
Does it affect all test suites? or just a specific one and just a subset of that suite?
We want to fix this but understanding how bad is the problem will help us prioritize over/under other work.
In terms of priority, this problem affects one specific set of tests (in ecma/Date/15.9.5.8.js) on one or two days each month during three separate hour-long slots, and only on certain XP boxes.

The tests affected are still covered by other boxes, including other Windows ones, so their failing is at worst a bit of a nuisance due to recurring orange.


Regarding comment 7, I think you onle need http://support.microsoft.com/kb/928388 , but we should verify (see below) that the outdated time zone rules are indeed the problem.

Would it be possible to (manually) execute "(new Date(1301643000000)).toString()" in a JS shell or in the browser (see comment 4) on one of these boxes and see what that reports?

If that confirms my theory, then you can schedule the update for when works best for you, if it debunks my theory I could spend a bit more time on this while it's still fresh in my mind.
(In reply to comment #10)

Thanks for the context it will help a lot to prioritize it.

> Would it be possible to (manually) execute "(new
> Date(1301643000000)).toString()" in a JS shell or in the browser (see comment
> 4) on one of these boxes and see what that reports?

Running "javascript:alert((new Date(1301643000000)).toDateString())" returns "Thu Mar 31 2011" when I assume it is supposed to show "Fri Apr 01 2011".
Yeah, it's supposed to show "Fri Apr 01 2011"; it does on my XP SP3 install.
Priority: -- → P3
URL: http://support.microsoft.com/kb/928388
Whiteboard: [orange][orange:time-bomb] → [orange][orange:time-bomb] See comment 8
I've successfully applied the individual security update[1] to talos-r3-xp-001 and get the correct, expected date when I run the test from comment #11.

I'll try to get an OPSI package created this week to deploy this.

1. http://www.microsoft.com/downloads/en/details.aspx?FamilyId=66F1420C-DF2D-400B-A8A9-EF9061A9A3CA&displaylang=en
Assignee: nobody → coop
Status: NEW → ASSIGNED
Priority: P3 → P2
The exe file for the update is already in the staging OPSI file store. I've successfully installed this update to the 3 staging XP slaves already via OPSI.

For posterity, here's the update download page from Microsoft:

http://www.microsoft.com/downloads/en/details.aspx?FamilyId=66F1420C-DF2D-400B-A8A9-EF9061A9A3CA&displaylang=en###
Attachment #530024 - Flags: review?(armenzg)
Comment on attachment 530024 [details] [diff] [review]
Install the appropriate Windows update to get the required DST fixes

It looks good.

I am debating if we should have the uninstall step as well in case we have to back out.
Attachment #530024 - Flags: review?(armenzg) → review+
Comment on attachment 530024 [details] [diff] [review]
Install the appropriate Windows update to get the required DST fixes

(In reply to comment #47)
> I am debating if we should have the uninstall step as well in case we have to
> back out.

We don't really use this elsewhere, but it was simple enough to add in. Checked in with that change:

http://hg.mozilla.org/build/opsi-package-sources/rev/59379b57e0d0
Attachment #530024 - Flags: checked-in+
I've marked the package for install on all the production XP slaves.

Leaving the bug open for a few days to make sure we're getting proper uptake.
Looks like we have full pick-up here, but I guess we'll see for sure on 2011-06-01.
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Blocks: 677065
Whiteboard: [orange][orange:time-bomb] See comment 8 → [orange:time-bomb] See comment 8
Filed bug 878391 on the way our brand new slaves seem to be hitting either the same thing, or a similar thing, though I won't be surprised if a few instances get starred here.
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: