828449 - Phone doesn't change its time when switching from or to DST

Status: RESOLVED DUPLICATE of bug 827816

(Firefox OS Graveyard :: General, defect)

Description

[Tim Taubert [:ttaubert] (inactive)]

Some STR:

(1) Start the phone in Europe/Berlin and set the time to Sep 29th, 2:59am.
No automatic change.

(2) Start the phone in Europe/Berlin and set the time to Sep 29th, 1:59am.
No automatic change.

(3) Start the phone in Europe/Berlin and set the time to Oct 28th, 2:59am.
No automatic change.

(4) Start the phone in Europe/Berlin and set the time to Nov 4th, 1:59am.
No automatic change.

--------------------

1) Sep 29th is when Date.getTimezoneOffset() changes, see bug 827816 comment #18.
2) I tried the time it usually changes in America.
3) Oct 28th is the date it should actually change in 2012.
4) Nov 4th is the date where it should change in 2012 in America.

I'm not sure if or how we take this into account internally but the time is definitely wrong. This might be hidden by phones that get the time automatically via the network provider.

This *may* be related to bug 827816? Not sure.

Comment 1

[JP Rosevear [:jpr]]

Maybe bug 804988 related as well?

Comment 2

[Tim Taubert [:ttaubert] (inactive)]

(In reply to JP Rosevear [:jpr] from comment #1)
> Maybe bug 804988 related as well?

This may be related. I tried to always purge in purgeIfTZAIsStale() but it didn't make a difference.

I couldn't find any code related to how the JS Engine handles DST changes. Maybe it doesn't?

Comment 3

[Andrew Overholt [:overholt]]

Andrea, can you take a look?

Comment 4

[Benjamin Chen [:bechen]]

(In reply to Tim Taubert [:ttaubert] from comment #2)
> (In reply to JP Rosevear [:jpr] from comment #1)
> > Maybe bug 804988 related as well?
> 
> This may be related. I tried to always purge in purgeIfTZAIsStale() but it
> didn't make a difference.
> 
> I couldn't find any code related to how the JS Engine handles DST changes.
> Maybe it doesn't?
It doesn't. bug 804988 fix that the DTSoffsetCache is stale while change timezone.

This bug should be a duplication to bug 827816 seems it uses 1970's timezone offset instead given timezone. attachment 700209 [details] [diff] [review] should fix this bug too.

Comment 5

[Johnny Stenback (:jst)]

Ok, duping against bug 827816.

Comment 6

[mjh563]

(In reply to Tim Taubert [:ttaubert] from comment #0)
> 1) Sep 29th is when Date.getTimezoneOffset() changes, see bug 827816 comment
> #18.

Actually, the result of the code in bug 827816 comment 18 does show the change happens on 28th October as expected, not 29th September:

(1) The month in the Date constructor is 0-based, so month 9 is October, not September.
(2) The time of day is midnight if not specified, so the first date is midnight at the start of 28th and the second date is midnight at the start of 29th. The change happened between those two times, which is therefore on 28th.