1089494 - [System, Clock] When moving from CEST to CET, the displayed time is wrong

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia, defect, P2)

Description

[Julien Wajsberg [:julienw]]

STR:
1. be at a date where the timezone change automatically from summer time to winter time

Additional notes:
* in System > Date & Time, I have "set automatically"
* I have a working SIM that's connected to the network
* I did not reboot the phone

Here is what happened for me:
* the displayed time did not change (both in Clock and in System)
* in System > Date & Time, the displayed timezone is still the old one (UTC+2), and the time is the old one too (1 hour too late)
* the alarm was triggered _at the right time_, it means that, somewhere inside the phone, the time is correct.
* after rebooting the phone... no change.
* if I set the timezone manually, then it works.

Note: I use a v2.0 build on Flame-JB.

Blocking requested because: we can't have this wrong while everyone else have this right.

Comment 1

[Wayne Chang [:wchang]]

[Blocking Requested - why for this release]:

Noming for 2.1 given where we are with 2.0. We do need to investigate this.

Comment 2

[Pi Wei Cheng [:piwei] (inactive)]

QA-Wanted won't be able to reproduce this bug because we can't have 'Set automatically' enabled AND still be at a date/time where time automatically changes. Removing tag.

Comment 3

[Julien Wajsberg [:julienw]]

too bad, I should have asked qawanted when I reported the bug, 1 week before US changed ;)

Comment 4

[Andrew Overholt [:overholt]]

What can be done now?  Is there a way this can be tested or does this require (a bunch of) code inspection?

Comment 5

[Julien Wajsberg [:julienw]]

It might make sense to check what happens without 'Set automatically' on various timezones.

Comment 6

[Andrew Overholt [:overholt]]

Dylan, this is bad.  Someone was recently investigating clock issues, right?  Can you help make a call about what to do/block here?

Comment 7

[Marcus Cavanaugh [:mcav]]

Pinging :mwu and :arthurcc at the suggestion of folks on IRC; either of you have a suggestion as to who should take this?

Comment 8

[Arthur Chen [:arthurcc][inactive after 6/30]]

From the description it works if users set the time manually. As for automatic time gaia only sets time.clock.automatic-update.enabled and time.timezone.automatic-update.enabled. I am not sure how gecko handles it during the transition from summer time to winter time.

Comment 9

[Julien Wajsberg [:julienw]]

Note that I often have some issues when merely moving between timezones too. (and that I still use v2.0, so maybe this disappeared in newer versions too).

Comment 10

[Michael Wu [:mwu]]

Hey Dave, are you familiar with the time/clock code in Hal?

The only person left who worked on bug 714358 is Steven Lee, so maybe he has some ideas.

Comment 11

[Dave Hylands [:dhylands]]

Just a guess here, but the internal UTC time doesn't change when crossing a daylight savings time boundary, just the timezone changes. So maybe we're not propagating the timezone change properly?

I  seem to recall that JS has its own internal notion of timezone that needs to be updated independently of the environment variables used by the runtime library.

We need to make sure that the timezone change is properly propagated to all of the running processes (since they will have already been setup to run on the previous timezone).

Question: Does the "Automatic Time change" when daylight savings time changes change just the timezone?, or just the time? or both?

Somebody should probably document the flow for date/time/timezone changes through the system, starting from the various sources that change things.

I think the sources are:
1 - the modem (NITZ)
2 - Over Wifi (NTP)
3 - From the settings app (manual change)
4 - From the command line (date command)

Comment 12

[StevenLee[:slee]]

(In reply to Dave Hylands [:dhylands] from comment #11)
> Just a guess here, but the internal UTC time doesn't change when crossing a
> daylight savings time boundary, just the timezone changes. So maybe we're
> not propagating the timezone change properly?
yes, that API callbacks only when system clock changes. It doesn't handle the modification of timezone. I think when someone changes timezone, they should also notify gaia about it.

Comment 13

[Andrew Overholt [:overholt]]

Stephany and I spoke about this again today during triage and we're not sure what blocking+ will do here.

Comment 14

[bhavana bajaj [:bajaj]]

(In reply to StevenLee[:slee] from comment #12)
> (In reply to Dave Hylands [:dhylands] from comment #11)
> > Just a guess here, but the internal UTC time doesn't change when crossing a
> > daylight savings time boundary, just the timezone changes. So maybe we're
> > not propagating the timezone change properly?
> yes, that API callbacks only when system clock changes. It doesn't handle
> the modification of timezone. I think when someone changes timezone, they
> should also notify gaia about it.

OK, looks like you know what's going-on here, so can you help with a patch ? We are also trying to see if QA is able to simulate this scenario and help reproduce/test.

Comment 15

[No-Jun Park [:njpark]]

So according to Andrew's suggestion, we can simulate the time change by setting the wifi router's time, or change the ntp server setting in the wifi router, and connect the flame device to the wifi  putting qawanted here to reproduce the issue.

Comment 16

[Rachel Pribble [:rpribble]]

We are unable to complete this task, as the date on our router is not able to be manipulated (we only have the option to change time zone). 
I used another Flame to set the date to just before Daylights Saving's Time occurs and created a hotspot with said device, then connected to it over wifi with my Flame, but my Flame did not roll back when the other device did.

Comment 17

[Andrew Overholt [:overholt]]

(In reply to No-Jun Park [:njpark] from comment #15)
> So according to Andrew's suggestion, we can simulate the time change by
> setting the wifi router's time, or change the ntp server setting in the wifi
> router, and connect the flame device to the wifi  putting qawanted here to
> reproduce the issue.

Yeah, I was thinking we could set up an ntp server on a local wifi network and have a device without a SIM get its time from that.

Comment 18

[StevenLee[:slee]]

Julien Wajsberg [:julienw] from comment #0)
> Here is what happened for me:
> * the displayed time did not change (both in Clock and in System)
> * in System > Date & Time, the displayed timezone is still the old one
> (UTC+2), and the time is the old one too (1 hour too late)
> * the alarm was triggered _at the right time_, it means that, somewhere
> inside the phone, the time is correct.
Does it mean
1. before daylight saving(UTC+2), set an alarm on PM3:00
2. after daylight saving(UTC+3), at PM2:00(which should be PM3:00 in UTC+3) the alarm is activated.

I added some log to setTimezoneByNitz, [1]. It's called. If I skip this function, the timezone information from SIM card will not be passed to gaia. So I think the path from NITZ should be OK. Could it be the problem from telecom?

[1] http://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#2602(In reply to

Comment 19

[Julien Wajsberg [:julienw]]

So, we were in CEST (daylight saving, UTC+2), I have an alarm set up to ring at 7am every day.

After the change (to CET, UTC+1), the displayed time was still at UTC+2, as was the displayed timezone in Settings. But the alarm correctly rang at 7am (UTC+1, 8am was displayed).

I was using a v2.0 JB build too, so I'm sorry if this could have been fixed by an updated base build...

Comment 20

[StevenLee[:slee]]

After talking with the developer of clock app, he mentioned that alarms and time on system uses the same "clock". clock app does not do anything special. :(

As comment 18, the path of notifying timezone changed from SIM card seems works. I'm not sure could it be the problem from NTP?

Comment 21

[Tony Chung [:tchung]]

in-moztrap? to add a test for this in future testruns

Comment 22

[KTucker [:KTucker][Inactive 3/4/2016]]

Test case has been added in moztrap: https://moztrap.mozilla.org/manage/case/15057/

Comment 23

[bhavana bajaj [:bajaj]]

(In reply to StevenLee[:slee] from comment #20)
> After talking with the developer of clock app, he mentioned that alarms and
> time on system uses the same "clock". clock app does not do anything
> special. :(
> 
> As comment 18, the path of notifying timezone changed from SIM card seems
> works. I'm not sure could it be the problem from NTP?

Probably, RIL team is in a better state to look at it to help narrow down further. Shawn, seeking your help here, please feel free to redirect to other folks as needed to diagnose this issue.

we may not be able to block on this at this point depending on how the fis is but we need to fix it soon.

Comment 24

[shawn ku [:sku]]

Since there is no log for us to check, I can only share some information I know here.

1. Date and time can be obtained via below.
   - NITZ via operator
   - SNTP request when there is any data connection or wifi.
2. Time zone can only be obtained via below.
   - NITZ

By checking what described in comment 0, it is weird to me that time is in-correct, but alarm works correctly. My expectation should be, time is wrong, alarm does not work in correct time either.
or time is correct, alarm works in correct time too.

Please ni me again once find a way to repo. or log is available although it is pretty hard I think.

Comment 25

[bhavana bajaj [:bajaj]]

I am removing blocking for this for 2.1 given the time we have and since this is not a new regression. But we need a way to fix this in 2.2.

Shawn, given the issue is hard to reproduce since its more obvious only during the DST changes, can dev's simulate some of these events/messages and test our code ? More ideas for QA to reproduce this are welcome to be able to give you the logs you need.

Comment 26

[Stephany Wilkes]

B2G triage blocking on this, as we are the family of time related bugs.

Comment 27

[Dylan Oliver [:doliver]]

Shawn, now that this is 2.2+ can you suggest the right component to help get this bug to the right team?

Comment 28

[shawn ku [:sku]]

(In reply to Dylan Oliver [:doliver] (Away until 23 Feb) from comment #27)
> Shawn, now that this is 2.2+ can you suggest the right component to help get
> this bug to the right team?

Hi Dylan:
 After reading whole comments, I still can not find the STR for how to repo. this case.
W/o STR, I don't think there is anyone who can help with this issue.

To me, it might be Gaia issue.
The reason I said it might be Gaia issue was because alarm works fine (per comment 0), it means system RTC/time work properly. Just some app had wrong time display. But, we still need STR to prove this viewpoint.

Comment 29

[Julien Wajsberg [:julienw]]

Shawn, is there a way to simulate the time change? For example adding some code in Gecko to simulate it, or using the emulator?

That's the only way we'll be able to replicate the issue without waiting for the next timezone change... We should be able to do it, right?

Comment 30

[shawn ku [:sku]]

(In reply to Julien Wajsberg [:julienw] from comment #29)
> Shawn, is there a way to simulate the time change? For example adding some
> code in Gecko to simulate it, or using the emulator?
> 
> That's the only way we'll be able to replicate the issue without waiting for
> the next timezone change... We should be able to do it, right?

Julien:
 1. There is no any emulator command to simulate NITZ event so far.
 2. we definitely can modify gecko for whatever we want, however, we still don't know if NITZ or SNTP cause this issue.
    Any hint for what to change in gecko side?

Comment 31

[Julien Wajsberg [:julienw]]

No I know nothing about this, sorry..

Comment 32

[howie [:howie]]

Hi Hsin yi, can you help to have a look on this? Thanks

Comment 33

[Ken Chang[:kenkai]]

(In reply to howie [:howie] from comment #32)
> Hi Hsin yi, can you help to have a look on this? Thanks
Hi Hsinyi, Can someone from your team study NITZ or NTP for fixing this bug?

Comment 34

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Ken Chang[:ken](OOO from 2/18 to 3/1) from comment #33)
> (In reply to howie [:howie] from comment #32)
> > Hi Hsin yi, can you help to have a look on this? Thanks
> Hi Hsinyi, Can someone from your team study NITZ or NTP for fixing this bug?

We will take a look first, though I agree with Shawn's comment 28 that it seems not directly NITZ or SNTP issue, it might be something deeper somewhere. Anyway, let us investigate first.

Comment 35

[Jessica Jong [:jessica] (inactive)]

Here are some facts about NITZ and NTP:

- NITZ gives time, timezone and dst info (dst is optional, and apparently we are not doing anything with the dst received). The timezone already includes dst, no need to apply dst to timezone.
- NTP gives time in UTC only.
- NITZ priority is higher than NTP
- Not all operators support NITZ [1], and it is usually issued upon registering on the network.
- In short, RIL sets time using nsITimeService and sets timezone by applying the 'time.timezone' settings. Both will eventually call into GonkHal.cpp. GonkHal will set the time/timezone properly and broadcast the message which is observed by TimeChangeObserver.cpp. TimeChangeObserver then fires the "moztimechange" event to gaia.

What I can do now is make a quick patch in emulator to support issuing NITZ command from emulator console and see if we can reproduce anything. I also need to check with gaia how clock, system and alarm app gets the date time.

Note that I found another similar bug (Bug 804988), but the timezone was selected manually there.


[1] http://en.wikipedia.org/wiki/NITZ

Comment 36

[Jessica Jong [:jessica] (inactive)]

Oh, and I think DST starts this weekend in the US, right? Can we take this chance to see if this can be reproduced using the latest master + flame? Let's see what logs to enable...

Comment 37

[Jessica Jong [:jessica] (inactive)]

From my tests, faking nitz changes reflect correctly in status bar time and clock app.
Can we have someone in the US test this in real life this weekend [2] to see if this is still an issue? Please use a sim card that supports NITZ [1] and enable ril logs [2].

Please verify time in status bar and clock app after dst starts but please DO NOT open the "Settings > Date & Time" page at anytime, since it is known that it may alter the system time based on mcc/mnc.

[1] http://www.timeanddate.com/time/change/usa/san-francisco
[2] http://en.wikipedia.org/wiki/NITZ
[3] https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#RIL_Debugging

Comment 38

[Jessica Jong [:jessica] (inactive)]

correct reference number :p

(In reply to Jessica Jong [:jjong] [:jessica] from comment #37)
> From my tests, faking nitz changes reflect correctly in status bar time and
> clock app.
> Can we have someone in the US test this in real life this weekend [1] to see
> if this is still an issue? Please use a sim card that supports NITZ [2] and
> enable ril logs [3].
> 
> Please verify time in status bar and clock app after dst starts but please
> DO NOT open the "Settings > Date & Time" page at anytime, since it is known
> that it may alter the system time based on mcc/mnc.
> 
> [1] http://www.timeanddate.com/time/change/usa/san-francisco
> [2] http://en.wikipedia.org/wiki/NITZ
> [3] https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#RIL_Debugging

Comment 39

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Also, we are interested in the behaviour of reference phones (android, iOS) that when there's neither SIM nor data connection (neither 3g nor wifi), how does the phone time behave with regard to DST? Does the time adjusted correctly? It's really appreciated if someone could test this for us, too. :)

Comment 40

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #38)
> correct reference number :p
> 
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #37)
> > From my tests, faking nitz changes reflect correctly in status bar time and
> > clock app.
> > Can we have someone in the US test this in real life this weekend [1] to see
> > if this is still an issue? Please use a sim card that supports NITZ [2] and
> > enable ril logs [3].
> > 
> > Please verify time in status bar and clock app after dst starts but please
> > DO NOT open the "Settings > Date & Time" page at anytime, since it is known
> > that it may alter the system time based on mcc/mnc.

Since in FTU there's "Date & Time" setup page, the system time may be altered unexpectedly as well. Please avoid reproducing this issue when you are in FTU for the sake of narrowing down the issue scope.

> > 
> > [1] http://www.timeanddate.com/time/change/usa/san-francisco
> > [2] http://en.wikipedia.org/wiki/NITZ
> > [3] https://wiki.mozilla.org/B2G/QA/Tips_And_Tricks#RIL_Debugging

Comment 41

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hello Kevin,
Could you please comment 37 ~ comment 40? Thank you!

Comment 42

[KTucker [:KTucker][Inactive 3/4/2016]]

Sure thing. I'll make sure this gets tested this weekend and report back the results here.

Comment 43

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: one_sim.txt

I set up 3 different phones over the weekend and left logcats running for each.\

One had a single sim with no wifi, another had two sims with no wifi, and the third had no sim but was connected to wifi.  As of this morning all 3 devices had correctly moved an hour forward.

Attaching all 3 logcats.

Comment 44

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: two_sims.txt

Comment 45

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: no_sim_wifi.txt

Comment 46

[shawn ku [:sku]]

Hi Julien,
 Since we had DST change recently, did you still hit this issue?

Besides, could you please help double confirm the SIM you use with NITZ support (or provide adb log with RIL enabled for us to check)?

Comment 47

[Jessica Jong [:jessica] (inactive)]

Thanks for the update Jayme. It's good new that time was correct after DST. However, I am little surprised with the result of the device 'no sim but connected to wifi'. This case, there is only information from NTP, but NTP does not contain timezone information, so it has no way to tell about DST. We need to dig more about this...

Comment 48

[Kai-Chih Hu [:khu]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #47)
> Thanks for the update Jayme. It's good new that time was correct after DST.

Does it mean that, after DST, the changes of timezone doesn't have any problem. But, before the DST change, it has problem? So, in this case, this bug is still valid, right? 

> However, I am little surprised with the result of the device 'no sim but
> connected to wifi'. This case, there is only information from NTP, but NTP
> does not contain timezone information, so it has no way to tell about DST.
> We need to dig more about this...

So, it sounds like you found another issue... ?

Comment 49

[Jessica Jong [:jessica] (inactive)]

(In reply to Kevin Hu [:khu] from comment #48)
> (In reply to Jessica Jong [:jjong] [:jessica] from comment #47)
> > Thanks for the update Jayme. It's good new that time was correct after DST.
> 
> Does it mean that, after DST, the changes of timezone doesn't have any
> problem. But, before the DST change, it has problem? So, in this case, this
> bug is still valid, right? 
> 

According to Jayme, the time moved forward after DTS started, that is, time was correct before and after DST. So I think this bug is not valid anymore. We can wait for Julien's feedback though.

> > However, I am little surprised with the result of the device 'no sim but
> > connected to wifi'. This case, there is only information from NTP, but NTP
> > does not contain timezone information, so it has no way to tell about DST.
> > We need to dig more about this...
> 
> So, it sounds like you found another issue... ?

Hmm, I was just wandering how the device was aware of the timezone change with only NTP information. After digging more, it seems that bionic libc can get the correct timezone offset using tzdata[1].


[1] http://cs.ucla.edu/~eggert/tz/tz-link.htm

Comment 50

[Julien Wajsberg [:julienw]]

(In reply to shawn ku [:sku] from comment #46)
> Hi Julien,
>  Since we had DST change recently, did you still hit this issue?

Actually the DST change in France is at the end of this month. I'll make sure to have several phones ready to report.

Comment 51

[Bobby Chien]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #49)
> (In reply to Kevin Hu [:khu] from comment #48)
> > (In reply to Jessica Jong [:jjong] [:jessica] from comment #47)
> > > Thanks for the update Jayme. It's good new that time was correct after DST.
> > 
> > Does it mean that, after DST, the changes of timezone doesn't have any
> > problem. But, before the DST change, it has problem? So, in this case, this
> > bug is still valid, right? 
> > 
> 
> According to Jayme, the time moved forward after DTS started, that is, time
> was correct before and after DST. So I think this bug is not valid anymore.
> We can wait for Julien's feedback though.
> 
> > > However, I am little surprised with the result of the device 'no sim but
> > > connected to wifi'. This case, there is only information from NTP, but NTP
> > > does not contain timezone information, so it has no way to tell about DST.
> > > We need to dig more about this...
> > 
> > So, it sounds like you found another issue... ?
> 
> Hmm, I was just wandering how the device was aware of the timezone change
> with only NTP information. After digging more, it seems that bionic libc can
> get the correct timezone offset using tzdata[1].
> 
> 
> [1] http://cs.ucla.edu/~eggert/tz/tz-link.htm

close as comment 49.

Comment 52

[Julien Wajsberg [:julienw]]

The issue happened with my 2.1 Open C (remember it originally happened on 2.0 Flame when I filed the bug).

It _did not_ happen with my Flame on master.

Additional info:
* when I set up the alarm yesterday:
 - on the Flame it correctly showed the time delay before the alarm.
 - on the Open C, the time delay shown had one hour too many.
* The alarm did not work on the 2.1 Open C... and I actually disabled it on the Flame so I could not check it. This is different to what I reported in my first comment. (and actually makes more sense).
* I have a SIM in both phones.

I remembered very late about this so I didn't set up my phones to fetch logs :(
I also did not have a 2.2 phone nor a 2.1 Flame...


Reopening because maybe it's possible to try this again on 2.1 (instead of master) in emulator?

Comment 53

[Julien Wajsberg [:julienw]]

I'll try to keep my phone in this situation for some time even if it's not really convenient. Jessica please tell me if you'd like me to fetch information on the phone using adb.

Comment 54

[Julien Wajsberg [:julienw]]

Too bad, the phone switched to the new time during the day...

Comment 55

[Julien Wajsberg [:julienw]]

New information (I didn't expect that) !

Today, my 2.1 phone's alarm triggered at the correct time... but it showed a bad alarm time while ringing !!
The time set was 7:30 am (which is 6:30am old time). It correctly triggered at that time (new time) but showed... 8:30am.

Note that I didn't touch it since we changed time. So last time this specific alarm triggered was last Friday (the one I set yesterday was another alarm).

I'm not sure what we can learn from this. We'll see if tomorrow's alarm has no issue.

Comment 56

[Julien Wajsberg [:julienw]]

Today the 2.1 phone's alarm triggered the correct time displaying the correct time too.

Comment 57

[Josh Cheng [:josh]]

Hi Julien,
From your comment it seems the issue cannot constantly reproduced. Should we wait until next daylight savings change?

Comment 58

[Julien Wajsberg [:julienw]]

Well, we can't do only 2 actions on this bug every year. This will be quite long to verify or fix.

We need to have an environment where we can reproduce this without waiting for DST change. This is really important so that user have confidence to our phone.

Comment 59

[Jessica Jong [:jessica] (inactive)]

Sorry, I missed this bug's update after coming back from PTO.

Let me summarize comment 52 - 56 and please correct me if I am wrong.
- on Flame master, everything worked as expected.
- on Open C 2.1, time switched like a day later? 
- on Open C 2.1, after switching to the correct time, the alarm triggered at the correct time but showing the wrong time.
- on Open C 2.1, afterwards, alarm triggered at the correct time and showing the correct time.

Since we don't have logs, we don't know when did the network send the correct time, therefore we can not tell whey time switched like one day later.
I can try to repro this on emulator v2.1, but please note that this bug has lower priority for me now.

Comment 60

[Julien Wajsberg [:julienw]]

(In reply to Jessica Jong [:jjong] [:jessica] from comment #59)
> Sorry, I missed this bug's update after coming back from PTO.
> 
> Let me summarize comment 52 - 56 and please correct me if I am wrong.
> - on Flame master, everything worked as expected.

The alarm was unfortunately not enabled so I couldn't check it was ringing at the right time. But when I enabled/disabled it previously the displayed text was right (on v2.1 it was not: the delay had 1 hour more).

> - on Open C 2.1, time switched like a day later? 

No, I'd say during the day following the change, but I don't know exactly when.

> - on Open C 2.1, after switching to the correct time, the alarm triggered at
> the correct time but showing the wrong time.

Yep.

> - on Open C 2.1, afterwards, alarm triggered at the correct time and showing
> the correct time.

Yep.


Maybe something that can be investigated is why the delay displayed by the Clock when I enabled the alarm was wrong. Where does this delay comes from? Is it returned by mozAlarm?

Comment 61

[Josh Cheng [:josh]]

[Blocking Requested - why for this release]:
Continue fixing on next release

Comment 62

[Mahendra Potharaju [:mahe]]

Wilfred, 
Can you please see if this is a blocker for 2.5 release? Thanks

Comment 63

[Ken Chang[:kenkai]]

In triage meeting, we think this is a critical issue for users.

Comment 64

[Jessica Jong [:jessica] (inactive)]

From comment 52, it was reproduced on 2.1 but not on master at the time, so it should not happen on 2.5, right?

Comment 65

[Julien Wajsberg [:julienw]]

And from comment 60 as well.

But as I said I didn't enable the alarm so I don't know if the alarm worked properly... I won't be able to try on a real device before some months (next is October 2015). I don't know if manually changing the date+time to trigger this (and disabling automatic time sync) could help reproduce so that QA can try ?

Comment 66

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Builds that work for Open_C (Flame JB) are no longer being made for on PVT so we cannot help test this issue.  Excluding it from our queries.

Comment 67

[Francisco Jordano [:arcturus] [:francisco]]

:JMercado, is this reproducible on the flame and z3c?

Comment 68

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

This issue did not occur when I tested this with a DST change on comment 43.  However the symptoms that Julien noticed with alarm can be manually reproduced without a DST change by manually changing your region/city to somewhere else and then re-enabling automatic date/time settings.

Comment 69

[Ken Chang[:kenkai]]

Samuel, can this bug be fixed by your solution on bug 1209892?

Comment 70

[Samael Wang [:freesamael] (away for now)]

(In reply to Ken Chang[:ken] from comment #69)
> Samuel, can this bug be fixed by your solution on bug 1209892?

comment 0 doens't look quite the same thing. If it shows "UTC+2" in settings while the country has switched back to UTC+1 due to the end of DST, it indicates no NITZ update was received from the operator network. NITZ is unsolicited so unless the base station sends update, the handset won't be able to get correct timezone automatically.

OTOH, the symptom that Clock app shows different time than Settings or the status bar could possibly be bug 1209892 or bug 1210093.

Comment 71

[Mahendra Potharaju [:mahe]]

[Tracking Requested - why for this release]:

As dependent bugs are 2.5+, removing blocker flag from this bug. 

Need to track this after the dependent blockers are fixed and closed.

Comment 72

[Johan Lorenzo [:jlorenzo]]

Last weekend, Europe has switched back in winter time. The night it happened, I set up 4 flames to try to catch the behaviors:
* 1 with 1 SIM that listens to the NITZ packed ("set automatically" being on)
* 1 with 1 SIM but "set auto" is off. I had to deactivate it from the settings, though
* 1 with no SIM card and no Wi-Fi connection. It has always remained at the DST time.
* 1 with a Wi-Fi connection but no SIM card. I couldn't activate "set auto" before the end of DST occured. The option wasn't displayed on the UI. It wasn't there 10 hours after, but I noticed it the following. The time was not correct, by the way: instead of showing 11:05, it showed 3:47. 

I made sure they were all set at the correct date and correct timezone (in my case Europe/Paris), before 2am started. On each of them, at 2:30am DST, I set up an alarm for 2:03am winter time. The first 2 devices showed "The alarm is set for 33 minutes from now", and they rang at the expected time. 
The 3rd and 4th devices showed that the alarm was set for 23h27 minutes from now, and they rang the next day.

I also left my dogfood device with an alarm set before DST changed. It rang at the correct time, the correct day. That's an improvement compared to last year, where my alarm rang an hour later.

However, I think some scenarios are missing in my testing. For instance:
* 1 device with a SIM and Wi-Fi, and "set auto" on
* 1 device with a SIM but "set auto" has never been toggled on
* 1 device with a SIM, "set auto" turned off more than a day ago (to see if the carrier per-emptively sends a NITZ packet)
* 2 devices with no SIM, connected to Wi-Fi, with set auto on. It'll likely require more than a day to get in that state. I recommend 1 flame and 1 aries. I'm guessing there a discrepancy between the 2 gonks.
* 1 device with a SIM, where "set auto" can't be turned on. The carrier doesn't support it. I remember either AT&T or T-Mobile does, in the US.

NI'ing Kevin, for QAnalyst to test these scenarios the the upcoming DST end in America.

Comment 74

[alex_mayorga]

¡Hola Julien!

FWIW I have a Flame that is still one hour ahead since Mexico DST ended last weekend.

Anything wort collecting fro the device?

¡Gracias!
Alex

Comment 75

[Julien Wajsberg [:julienw]]

Hey Alex :)

Redirecting the request to Johan and Samael. They might have better ideas than mine.

In the mean time, can you give the outputs of the commands:

* adb shell date
=> can you also give the time as displayed by the Flame at this moment ?
* adb shell getprop persist.sys.timezone
* adb shell getprop | grep nitz
* adb shell getprop persist.timed.enable

Can you also tell us if you have "set automatically" in Settings > Date & Time ?

Comment 76

[Samael Wang [:freesamael] (away for now)]

We just phased-in the solution for bug 1209892 today. I wonder if someone in the America can use the  nightly image tomorrow (or just build it locally with latest code) to see if the end of DST on Nov. 1 goes smooth.

Comment 77

[Johan Lorenzo [:jlorenzo]]

(In reply to Julien Wajsberg [:julienw] from comment #75)
`adb logcat -v threadtime` can tell us if the system clock is at the same time as the one displayed on the status bar. If times are different, this is due to bug 1208808.

Comment 78

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Johan Lorenzo [:jlorenzo] (QA) from comment #77)
> (In reply to Julien Wajsberg [:julienw] from comment #75)
> `adb logcat -v threadtime` can tell us if the system clock is at the same
> time as the one displayed on the status bar. If times are different, this is
> due to bug 1208808.

According to bug 1208808 comment 21, the discrepancy has been resolved by bug 1209892.

Comment 79

[Zibi Braniecki [:zbraniecki][:gandalf]]

Not necessarily. What we got is that Date and ICU *timezones* are in sync (and km still not sure if it covers cet/cest). Time can still be off (that's what bug 1208808 patch is fixing) and time between system and spidermonkey may be off as well I believe.

Comment 80

[alex_mayorga]

¡Hola Julien, Johan!

Here's the requested data:

$ adb shell date
Fri Oct 30 11:52:40 CST 2015

The displayed time on the Flame lock screen was 12:52 though...

$ adb shell getprop persist.sys.timezone
America/Monterrey

$ adb shell getprop | grep nitz
[persist.rild.nitz_long_ons_0]: []
[persist.rild.nitz_long_ons_1]: []
[persist.rild.nitz_long_ons_2]: []
[persist.rild.nitz_long_ons_3]: []
[persist.rild.nitz_plmn]: []
[persist.rild.nitz_short_ons_0]: []
[persist.rild.nitz_short_ons_1]: []
[persist.rild.nitz_short_ons_2]: []
[persist.rild.nitz_short_ons_3]: []

$ adb shell getprop persist.timed.enable
true

"Set Automatically" is turned on in "Settings > Date & Time"

Build Identifier is 20151023030241

Tried Johan command too but got no output:

$ `adb logcat -v threadtime`


Do let me know if there's anything you need.

¡Gracias!
Alex

Comment 81

[Julien Wajsberg [:julienw]]

> $ `adb logcat -v threadtime`

Without the ` ;)



Samael, do these result make sense to you ?

Comment 82

[Johan Lorenzo [:jlorenzo]]

Julien provided an answer in comment 81.

Comment 83

[Samael Wang [:freesamael] (away for now)]

(In reply to Julien Wajsberg [:julienw] from comment #81)
> > $ `adb logcat -v threadtime`
> 
> Without the ` ;)
> 
> 
> 
> Samael, do these result make sense to you ?

The specific result in comment 80 is more likely to be bug 1210093. I can reproduce it without enabling automatic time with the following steps:

1. Set the timezone to America/Monterrey manually (disable automatic time).
2. Change the date to any one between Oct. 25 ~ Oct. 31, 2015.
3. Launch Clock app.
4. The display time of clock app should have one hour difference than the display time of status bar.
5. Change the date to Nov. 1, 2015 or later.
6. The display time of clock app should be the same as on the status bar.

Comment 84

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Johan we did the testing requested to the best of our ability during the DST changeover this weekend.  Here are the results:

1 device with a SIM and Wi-Fi, and "set auto" on - Flame device had correct time and alarms/calendar notifications were migrated correctly.

1 device with a SIM but "set auto" has never been toggled on - We coould not really test this.  Not having a SIM or Wifi caused set auto to be off by default, but as soon as a SIM was inserted set auto was on.  We turned it off asap on a Flame device and everything migrated correctly.  However this was more akin to the test below isntead.

1 device with a SIM, "set auto" turned off more than a day ago (to see if the carrier per-emptively sends a NITZ packet) - Aries device had correct time and alarms/calendar notifications were migrated correctly.
	
2 devices with no SIM, connected to Wi-Fi, with set auto on. It'll likely require more than a day to get in that state. I recommend 1 flame and 1 aries. I'm guessing there a discrepancy between the 2 gonks. - Both Flame and Aries devices had correct time and alarms/calendar notifications were migrated correctly.

1 device with a SIM, where "set auto" can't be turned on. The carrier doesn't support it. I remember either AT&T or T-Mobile does, in the US. - Both TMobile and ATT support DST so we could not check this


Environmental Variables:
Device: Aries 2.6
BuildID: 20151030120435
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: c2534acb485963331d67bbc5c07f0d862ed56bf5
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20151030004507
Gaia: 91cac94948094cfdcd00cba5c6483e27e80cb3b0
Gecko: 138dd4cdf44e10d1f713942c180b9f92567052f6
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Comment 85

[Jayme Mercado [:JMercado] (Inactive 3/4/2016)]

Attachment: DST_logcats.zip

Here are the logcats for 3 of the devices tested from the above comment.

Comment 86

[Johan Lorenzo [:jlorenzo]]

Thanks for the testing. I don't see any NITZ packets in the logs where "set auto" was turned off. I guess that's because the RIL output wasn't enabled. I should have mentioned that in comment 72 :S

Comment 87

[Hsin-Yi Tsai (she/her) [:hsinyi]]

I just used the latest emulator-x86-kk build to verify this issue, originally reported on comment 0 - when timezone changes from CEST to CET or vice versa, the displayed time is adjusted correctly. I think it's time to close this bug?

How I verified:
1) launch emulator-x86-kk, go to Settings/Date & Time
2) use emulator console command "gsm timezone" to simulate network NITZ events
3) first typed "gsm timezone 8" (which means UCT+2) on console (via "telnet localhost 5554") and observed the result which was correctly updated
4) typed "gsm timezone 4" (which means UCT+1) and observed the result which changed correctly

Comment 88

[Julien Wajsberg [:julienw]]

Let's close this then ! I'll be sure to reopen if I see this again ;)

Comment 89

[Julien Wajsberg [:julienw]]

Well, this happened again when we moved to CEST last saturday.

I guess this is not the same code path is in comment 87: we don't change the timezone, but the timezone itself changes. Especially I don't think we get a NITZ event in that case, rather the libc knows about the summer time change for this timezone.

Comment 90

[Julien Wajsberg [:julienw]]

Maybe it's easy to reproduce manually by setting the date and time just before the time change ?

Comment 91

[Julien Wajsberg [:julienw]]

Note the issue happens only when I have "set automatically" enabled. When I manually selects the Paris timezone the time is correct.

Comment 92

[BMO Automation]

Firefox OS is not being worked on