Firefox OS v1.3 Mozilla build ID: 20140208004002 Created an attachment (id=650020) ko picture DEFECT DESCRIPTION: Date&time on status bar display inconsistent with data&time in time setting REPRODUCING PROCEDURES: 1.Enter "Settings--> date &time",set automatically off,,modify "Time zone_> region /city" 2. Compare date&time on status bar with date&time in time setting;Date&time inconsistent with date&time in time setting.--KO. Note:Beetle lite FF is OK. EXPECTED BEHAVIOUR: Date&time display on status bar should consistent with date&time in time setting. ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: REPRODUCING RATE: For FT PR, Please list reference mobile's behavior:

Can someone confirm this on the Moz side?

Confirming that this occurs on Buri 1.4 When the date / time is set to automatic but the user is in a different time zone than is set (New York when in Seattle, for instance) the times can become mismatched. 1.4 Environmental Variables: Device: Buri 1.4 MOZ BuildID: 20140228040203 Gaia: 9422aca1931ba6c68784f9e80bb1b6a7fcfd92e3 Gecko: 58eca03214a6 Version: 30.0a1 Firmware Version: v1.2-device.cfg

Also confirming for 1.3, since this was the branch it was found on. 1.3 Environmental Variables: Device: Buri 1.3 MOZ BuildID: 20140228004002 Gaia: 9e439c98a05bde90b571701ef0b2dbb4249ef196 Gecko: 7fb42ba60248 Version: 28.0 Firmware Version: v1.2-device.cfg Side note: This can happen immediately when turning automatic off as well.

So this is a regression caused by fixing something else. Can we check what regressed this and back out the same?

Wondering if this is a status bar issue. Gregor, please help here.

dears, This is same reason as PR 965912, maybe you could close it.

(In reply to Ray REN from comment #8) > dears, > > This is same reason as PR 965912, maybe you could close it. I don't think so. That bug landed on 2/18 & was verified fixed on 2/19. This was confirmed busted on 2/28.

(In reply to Jason Smith [:jsmith] from comment #9) > > I don't think so. That bug landed on 2/18 & was verified fixed on 2/19. This > was confirmed busted on 2/28. Sorry my mistake. Before I merge the patch in PR 965912, the status bar's display is OK and date&time's display is KO. After merged 965912's patch, the status bar's display is KO and date&time's display is OK. Please check that patch. Thanks.

Looking into this Fairly confused as to why my 'set automaticcaly' checkbox is gone, despite this code not changing for ~4 months

I can reproduce this on master Still confused as to why I need to manually set time.clock.automatic-update.enabled, true only on master

ok, a regression window would be interesting because as far as I can tell this will always have worked the same way, its also fairly visible Setting the timezone triggers some gonk code to set the android timezone, its not used anywhere else, our jsapi code as far as I can uses plain system calls to read the time (http://mxr.mozilla.org/mozilla-central/source/js/src/prmjtime.cpp), so kinda seems like those system calls dont pick up android timezone changes (done via env vars?), when restarted / new processes are all fine. With only guessing whats going wrong, assume the fix would be to have PRMJ_Now(void) ifdeffed on android needinfoing Dave as he made the mistake of answering on irc, I am guessing at most of this stuff, is any of that along the right lines?

So more looking, |$ date| at the command like will take the new timezone into account, I can only see jsdate.cpp doing a straight path to system calls which sound like they 'should' do the right thing, however informed on IRC that we may cache the timezone somewhere and sstangl might know more, any ideas?

This issue looks to have started reproducing on the 02/18/14 1.3 build. The following regression window was found using tinderbox builds: - Last Working - BuildID: 20140218130433 Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190 Gecko: 3d3021fdb54f Version: 28.0 Firmware Version: V1.2-device.cfg - First Broken - Device: Buri v1.3 MOZ RIL BuildID: 20140218135733 Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190 Gecko: 42944ee96dd0 Version: 28.0 Firmware Version: V1.2-device.cfg *This issue looks to be a gecko issue* last working gaia/first broken gecko = REPRO Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190 Gecko: 42944ee96dd0 first broken gaia/last working gecko = NO REPRO Gaia: 77cc5367781d5770b4d94d8746cf4f5ecd80d190 Gecko: 3d3021fdb54f Since there was only one gecko commit between these two, I thought it unnecessary to use inbound builds for a deeper regression window. Please NI me if more info is needed though. Push Log: http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/pushloghtml?fromchange=3d3021fdb54f&tochange=42944ee96dd0

This is a nuwa regression - bug 965912 is the cause of this. Kyle or Cervantes - Can you look into this?

so js/ is getting the same time from the system and modifying it somewhere before returning different times to content ## Status Bar (System App) I/GeckoWTF( 2265): Date was 1394123760149.000000 E/GeckoConsole( 2265): Content JS LOG at app://system.gaiamobile.org/js/statusbar.js:617 in sb_updateTime: GeckoWTF - NOW IS Thu Mar 06 2014 17:36:00 GMT+0100 (CET) ## Settings App I/GeckoWTF( 2668): Date was 1394123759986.000000 E/GeckoConsole( 2668): Content JS LOG at app://settings.gaiamobile.org/js/date_time.js:45 in updateClock: GeckoWTF - NOW IS Thu Mar 06 2014 23:35:59 GMT+0700 (CET) (The "Date was" is printing the return from NowAsMillis and is the same time)

(In reply to Dale Harvey (:daleharvey) from comment #14) > So more looking, |$ date| at the command like will take the new timezone > into account, I can only see jsdate.cpp doing a straight path to system > calls which sound like they 'should' do the right thing, however informed on > IRC that we may cache the timezone somewhere and sstangl might know more, > any ideas? There is a cache of the timezone on the JSRuntime, along with the JSAPI call JS_ClearDateCaches() which may be used to notify each JSContext that the timezone has changed.

I'll look into it.

I think removing the code from nsLayoutStatictics causes the regression for the chrome process: the Nuwa process and its forked childs clear the cache, but the chrome process doesn't. It should be easy to fix.

Fix the regression caused by bug 965912. Risk analysis: InitDateCacheCleaner() was originally called in nsLayoutStatics::Inittialize() so each process will call in initializing the layout module. Bug 965912 move it from layout module initialization to ContentChild so it is called when each process is forked from Nuwa. This led to the regression that the chrome process doesn't initialize it. This bug add the InitDateCacheCleaner() call to ContentParent::StartUp() to fix the regression and should be safe.

Tests: https://tbpl.mozilla.org/?tree=Try&rev=aba7c9860048

Please request approval-mozilla-b2g28 on this when it is ready for v1.3 uplift.

Comment on attachment 8387399 [details] [diff] [review] Init date cache cleaner in ContentParent [Approval Request Comment] Bug caused by: bug 965912 User impact if declined: system time zone change not reflected on status bar. Testing completed: m-c manual tests. Risk to taking this patch (and alternatives if risky): low, since the regression in 965912 missed the initialization in ContentParent. This bug adds the initialization back to the chrome process.

Verified as fixed v1.3. This issue does NOT reproduce on the latest v1.3 build: 3/26 Environmental Variables: Device: Buri 1.3 MOZ RIL BuildID: 20140326004002 Gaia: 812838ad0fabf51fa14435af562ddac6d26fa936 Gecko: ba97efb0da4b Version: 28.0 Firmware Version: V1.2-device.cfg Verified as fixed v1.4. This issue does NOT reproduce on the latest v1.4 build: 3/26 Environmental Variables: Device: Buri 1.4 MOZ RIL BuildID: 20140326000201 Gaia: 7e705dd4718d528974d99ac31866318d7e201152 Gecko: 4889124accfa Version: 30.0a2 Firmware Version: V1.2-device.cfg - 1) I am currently unable to verify this issue on the v1.3T Branch, leaving verifyme keyword. 2) Changing bug status to verified as this was tested against master v1.4, comment #27.

Verified as fixed v1.3T. I am unable to reproduce this issue on the latest v1.3T Tarako build: v1.3T Environmental Variables: Device: Tarako v1.3T MOZ RIL BuildID: 20140530014002 Gaia: e68858693b71d917c9c5ee7e215f7ceea04635f7 Gecko: 1945abae19ff Version: 28.1 Firmware Version: SP6821a-Gonk-4.0-5-12