Closed Bug 610191 Opened 14 years ago Closed 10 years ago

xpcom\tests\unit\test_localfile.js | test failed during DST time change

Categories

(Core :: XPCOM, defect)

All
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: glandium, Unassigned)

References

Details

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

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1289121563.1289123486.23086.gz
TEST-UNEXPECTED-FAIL | e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-xpcshell/build/xpcshell/tests/xpcom/tests/unit/test_localfile.js | false == true - See following stack:
JS frame :: e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-xpcshell\build\xpcshell\head.js :: do_throw :: line 420
JS frame :: e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-xpcshell\build\xpcshell\head.js :: do_check_eq :: line 472
JS frame :: e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-xpcshell\build\xpcshell\head.js :: do_check_true :: line 484
JS frame :: e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-xpcshell/build/xpcshell/tests/xpcom/tests/unit/test_localfile.js :: test_file_modification_time :: line 114
JS frame :: e:/builds/moz2_slave/mozilla-central-win32-debug-unittest-xpcshell/build/xpcshell/tests/xpcom/tests/unit/test_localfile.js :: run_test :: line 52
JS frame :: e:\builds\moz2_slave\mozilla-central-win32-debug-unittest-xpcshell\build\xpcshell\head.js :: _execute_test :: line 303

This does sound related to DST time change.
It will either continue occurring until tomorrow, and then disappear, or continue until next daylight saving time change.
Bug 557539 introduced the test that is now failing. It landed in summer time.
Blocks: 557539
I don't have much time to go further right now, so in case this can be useful to someone else:
In nsLocalFile::SetModDate, I tracked the values set in nsLocalFile::SetModDate in xpcom/io/nsLocalFileWin.cpp, for st, lft and ft
st:
2010 11 6 8 27 20 345 (wYear, wMonth, wDay, wHour, wMinute, wSecond, wMillisecond)
lft:
1844365456 30113164 (dwLowDateTime, dwHighDateTime)
ft:
2081556624 30113231 (dwLowDateTime, dwHighDateTime)

lft comes from st through SystemTimeToFileTime, and ft from lft through LocalFileTimeToFileTime. The difference between ft and lft is 28800 seconds, i.e. 8 hours. At first glance, it looks like LocalFileTimeToFileTime doesn't care much about the fact that the given date is GMT-7 and not GMT-8 as current time is.
Quoting here for the record what I wrote on irc: if my assumptions are correct, it will be permaorange until tomorrow and then will work until next summer->winter time change.
Whiteboard: [orange][orange:time-bomb]
As suspected, this now doesn't occur anymore. Until next year.
Blocks: 438871
Did this bug occur around 13 March 2011?
I think bug 377307 fixed this (LocalFileTimeToFileTime is no longer used).
(In reply to comment #9)
> Did this bug occur around 13 March 2011?
> I think bug 377307 fixed this (LocalFileTimeToFileTime is no longer used).

I /think/ this bug occurs(ed?) only when switching from summer time to winter time.
Whiteboard: [orange][orange:time-bomb] → [orange:time-bomb]
Apparently comment 9 was right, and this was fixed by bug 377307.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.