Closed Bug 1208808 Opened 9 years ago Closed 9 years ago

Discrepancy between toLocaleFormat and toLocaleString when timezone is unresolved

Categories

(Core :: JavaScript: Internationalization API, defect, P2)

Product:
Core
Component:
JavaScript: Internationalization API
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla45
Project Flags:
tracking-b2g backlog
Tracking Flags:
Tracking Status
firefox45 --- fixed
b2g-v2.5 --- verified
b2g-master --- verified

People

(Reporter: zbraniecki, Assigned: Waldo)

References

(
URL
)

Details

(Whiteboard: [platform])

User Story

Video of the behavior: https://youtu.be/MwY1zItFY2E

Attachments

(2 files)

Sync up ICU time-updating with the JS engine's LocalTZA updating
71.47 KB, patch
till
: review+
Details | Diff | Splinter Review
flame-timezone-test.png
100.92 KB, image/png
Details 
Firefox OS provides an option of "automatic" timezone.

When selected, and probably when something goes wrong (bug 1208807), the timezone is not selected.

In that scenario, the behavior of "toLocaleFormat" and "toLocaleString" differentiate.

Steps to reproduce:

1) Time is 7:59pm in San Francisco
2) FxOS device is manually set in America/New_York timezone
3) var x = new Date();
4) x.toLocaleFormat(); // "Sat Sep 26 22:59:58 2015"
5) x.toLocaleString(navigator.language); // "9/26/2015, 10:59:58 PM"
6) x.getTimezoneOffset(); // 240
7) Switch "Set Automatically" timezone to on
8) var x = new Date();
9) x.toLocaleFormat(); // "Sat Sep 26 22:01:55 2015"
10) x.toLocaleString(navigator.language); // "9/27/2015, 3:01:55 AM"
11) x.getTimezoneOffset(); // 300

There seem to be a 5h difference between those two times.
User Story: (updated)
Jeff, do you know what may be going on here?
Flags: needinfo?(jwalden+bmo)
Which API is in the wrong?  I'd have assumed the "proper" behavior for 9/10 would have been to have 20:01 or so in them, not two/seven hours later.
Flags: needinfo?(jwalden+bmo) → needinfo?(gandalf)
So, steps 1-6 all look good. The timezone is 240 and the time should be 3 hours ahead of San Francisco.

Now, if the automatic timezone recognition worked properly, we might have get the San Francisco timezone in step 7, but we didn't.

Instead, `getTimezoneOffset` returns in step 11 a value "300" which is CDT, and I don't understand how - but my guess is that it's some sort of a fallback in case automatic timezone recognition works properly.

Either way, in step 9, you can see that `toLocaleFormat` is consistent with that - shows time an hour ahead of New_York.

But in step 10, toLocaleString is not. It seems to be falling back to GMT timezone.

GMT is a logical timezone to fall to. My only question is why those two localization approaches fall back to different things and is there a chance that we could make them fall back to the same one?

Does it ring any bell as to why those two code pieces react so differently?

I know that the limitation here is that I don't understand what does it really mean to "not recognize timezone automatically".
The closest thing I can find is in Gaia code here:
 - https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/modules/date_time.js#L17

and then in Gonk code here:
 - https://dxr.mozilla.org/mozilla-central/source/dom/system/gonk/RadioInterfaceLayer.js#52

But why would it trigger one change in old Date code and another in Intl code, I don't understand.

It's important because we do use Intl API and the "old" API interchangeably in Firefox OS and it leads to a very confusing UI with two different date/time settings displayed at the same time on the screen.

On top of that, until I get 'dayperiod' token into Intl API[0], we have to workaround it and remove the dayperiod token manually which requires us to use date.toLocaleFormat('%p') which because of this bug sometimes returns 'am', while Intl returns date with 'pm', and the removal doesn't work.

[0] https://github.com/tc39/ecma402/issues/29
Flags: needinfo?(gandalf) → needinfo?(jwalden+bmo)
I guessed it was related to bug 1198216 and bug 1172609, but after backing them out locally, I still saw the time in the Gaia status bar being on UTC time.

For the record, I reverted bug 1172609 part 1 and 5 to 9. I couldn't find where were part 2 to 4 neither in the git history, nor in Bugzilla.
See Also: → 1198216, 1172609
Date.prototype.toLocaleString consults Intl.DateTimeFormat.  That, ultimately -- I *think* -- consults the difference in times exposed by a single time created by t=time(3), then the difference in mktime(localtime(t)) and mktime(gmtime(t)) is used as the time zone.

Date.prototype.toLocaleFormat depends on the JS engine's computation of LocalTZA() to construct a local time from the Date.  It then does semi-similar things to ICU, that might generally have about the same behavior.

Now, LocalTZA() is determined by, approximately, the same stuff as ICU: time, mktime, localtime, gmtime, and some subtracting.  But there's a lag with a stale value used: until DateTimeInfo::updateTimeZoneAdjustment() is called, for the DateTimeInfo in the JSRuntime.  If that *doesn't* happen, then maybe things get out of sync, with "offsetting" local time adjustments not doing so, leaving us with a bogus time.

When is that method called?  Turns out, it's called randomly a few places, but possibly nothing affecting here.  Where it's *intended* to be called, is from a method JS_ClearDateCaches(JSContext*).  How's that method differ from JS::ResetTimeZone() that we added in bug 1172609?  Great question!  Looking now, I have *no idea* why we added both methods, rather than having the one method do both things.  Tunnel vision on my part?  Bah.

*If* that's the case, to fix this, we should get rid of one of these methods, then have the remaining one perform both ICU-notification, and LocalTZA updating.  This will be a little tricky: LocalTZA is thread-local and requires a JSContext*, while the ICU stuff is whole-process.  But nothing infeasible, just yak-shaving.

I'll see if I can whip up a hack-patch to test this theory, that wouldn't be a full fix but would give a yes/no, but it might be a few days.
CCing Ted to run comment 5 past him, and for a sanity check of the idea, and conceivably so he can test a quick hack-fix to verify the conclusion faster than I might before I'd go about implementing a full, correct fix.
Flags: needinfo?(jwalden+bmo)
[Blocking Requested - why for this release]:
This seems like a 2.5 blocker since it can make the phone show the wrong time for a timezone.
blocking-b2g: --- → 2.5?
Blocking for 2.5 with a P2 priority.
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2
See Also: → 1185701
I can take this, but my typing ability is a bit restricted by a sprained hand, so I'd rather avoid patch-writing typing for a week or so if possible.
Assignee: nobody → jwalden+bmo
Whiteboard: [platform]
Hi Jeff, can you provide an update on this issue?
Flags: needinfo?(jwalden+bmo)
[Tracking Requested - why for this release]:

All time zone issues are being handled in the dependent bug. 

Time zone code refactoring will be done soon to handle all timezone issues. 

Removing blocker flag and needs to be tracked and checked when dependent meta bug is fixed.
blocking-b2g: 2.5+ → ---
tracking-b2g: --- → backlog
Basically, to make ICU and the Date code sync up about time zone, we have to make them both update at the same time.  Because the ICU code updates every thread at once via shared state, so too must the Date code.  So I made the Date/DateTimeInfo stuff global, protecting it with a stupid spinlock.

Beyond that basic fix, a few other things to note/be aware of.

I combined JS_ClearDateCaches/JS::ResetTimeZone into the latter, as we only need one and never should have had two.

I moved various library-init stuff into a new js/public header.  The rationale was that I wanted DateTimeInfo::init to be private so that *only* JS_Init would call it.  That required a friendship be set up.  But that required js/src/vm/DateTime.h to depend on jsapi.h, a rather huge dependency.  So I moved the minimal bits into a new js/public/LibraryInitialization.h and a corresponding .cpp for it.

DateTimeInfo::updateTimeZoneAdjustment is also private, friended to JS::ResetTimeZone, because I was worried about someone calling that and not also updating ICU's time zone at the same time.

This not-total-locking around uses means that some Date methods will, unavoidably, potentially see different LocalTZA's at different times in a method, if they're truly unlucky.  The spec does sometimes do LocalTZA(), then reenter, then a separate LocalTZA(), so it's impossible to have a lock on the LocalTZA value because the reentry could change the value underneath you.  :-\  Too bad these methods weren't done with an eye to LocalTZA changing at all.

I renumbered/reordered a couple Date methods, as part of adding a real lock around LocalTZA.  Then I realized such wouldn't work due to reentry, so it's kind of unnecessary change.  I can undo it if required, but they seem like good changes and not horribly tricky, so I'm loathe to undo them just for a marginally cleaner review.

Anyway.  Nothing really crazy here, just a bunch of code motion and some spinlock/global protected state screwball.

Haven't tested whether this will actually fix the bug yet -- sending off to try first, and if someone b2g-related wants to test and verify it fixes things, great.
Attachment #8679696 - Flags: review?(till)
Flags: needinfo?(jwalden+bmo)
Comment on attachment 8679696 [details] [diff] [review]
Sync up ICU time-updating with the JS engine's LocalTZA updating

Review of attachment 8679696 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. I'm not entirely sure I like "LibraryInitialization" as a name, though. At least for me it's not at all clear that the library in question is SpiderMonkey itself. Perhaps "JSAPIInitialization"? Or just "Initialization"? Oddly, that seems clearer to me.

::: js/src/vm/LibraryInitialization.cpp
@@ +113,5 @@
> +    MOZ_ASSERT(libraryInitState == InitState::Running,
> +               "JS_ShutDown must only be called after JS_Init and can't race with it");
> +#ifdef DEBUG
> +    if (JSRuntime::hasLiveRuntimes()) {
> +        // Gecko is too buggy to assert this just yet.

I wonder if this is still true.
Attachment #8679696 - Flags: review?(till) → review+
[Blocking Requested - why for this release]:

[Blocking Requested - why for this release]: This bug makes all date/time formatting problems much more visible because it means that it happens fairly often that the dayperiod token in time string is 'am' while the dayperiod token in toLocaleFormat('%p') which we use to remove the dayperiod token from the time string is 'pm'.

Fixing it will mitigate this and many more discrepancies between our displayed time strings in various places in Firefox OS.
blocking-b2g: --- → 2.5?
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #16)
> [Blocking Requested - why for this release]:
> 
> [Blocking Requested - why for this release]: This bug makes all date/time
> formatting problems much more visible because it means that it happens
> fairly often that the dayperiod token in time string is 'am' while the
> dayperiod token in toLocaleFormat('%p') which we use to remove the dayperiod
> token from the time string is 'pm'.
> 
> Fixing it will mitigate this and many more discrepancies between our
> displayed time strings in various places in Firefox OS.

The specific symptom in comment 0 should be caused by bug 1209892. We've just phased in the solution to Flame-KK and Aries. You can give it a try.

It's considerable to mark this issue as duplicated and move Jeff's patch to a new bug of general improvement for our JS engine's Date and ICU synchronization issue.

One other problem is that ICU has it's own timezone database [1] and it's always possible to be not the same as underlying OS platform's one. We need a long term plan to deal with it.

[1] https://github.com/mozilla/gecko-dev/blob/master/intl/icu/source/data/misc/zoneinfo64.txt
See Also: → 1209892
Samael, we seem to have a patch in this bug which reduces discrepancy between two date systems in our JS. It seem to be going further than the patch that landed and will help us maintain more consistent UX.

The patch has r+.

Wouldn't it be better to land it (if possible, in time for 2.5) instead of moving to a new bug? Or am I missing something?
Flags: needinfo?(sawang)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #18)
> Samael, we seem to have a patch in this bug which reduces discrepancy
> between two date systems in our JS. It seem to be going further than the
> patch that landed and will help us maintain more consistent UX.
> 
> The patch has r+.
> 
> Wouldn't it be better to land it (if possible, in time for 2.5) instead of
> moving to a new bug? Or am I missing something?

I'm only saying that comment 0 doesn't actually caused by that, so you're safe to close this bug if the symptom blocks 2.5.

Landing an improvement of JS engine sounds good, of course.
Flags: needinfo?(sawang)
Since it's so late for 2.5 and Gecko 44 has already (or will be very soon) branched, it seems like we shouldn't block 2.5 on this and instead let this land in m-c and ride the trains until the next B2G release.  It also looks like we have a gonk-level fix in but 1209892.
blocking-b2g: 2.5? → ---
I can confirm that comment 0 STR is fixed with bug 1209892 on Flame-kk!

I agree that this no longer should block 2.5 but I'd love to get this landed right after branching so that if we encounter time discrepancy on the branch I can verify if this patch fixed it by just testing master.
https://hg.mozilla.org/mozilla-central/rev/7b23b9f96a36
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox45: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
While the general behavior of this issue seems to be much better, I am still able to reproduce the behavior of the duplicate bug 1210190 using the following steps:

1) Disable Set Automatically in Time settings, and set the timezone to be different from your current timezone (mine was New York)
2) Go to the homescreen and launch the Clock app
3) Leave the Clock app running, then switch back to Settings and re-enable Set Automatically. The time should update correctly to local time (UTC -08:00 for me)
4) Switch back to the Clock app. Note the analog clock has updated correctly, but the digital clock has not, and still displays the wrong time.
5) Create a new alarm,  note the time for the alarm is wrong.
6) Set the time, and note the time in the picker carousel is correct.

Environmental Variables:
Device: Flame 2.5
BuildID: 20151103030244
Gaia: 06de78d2c61c084956640c480280ba518b2fe29f
Gecko: bb4d614a0b09bcb9738c151dccfcd9b3857a6a7c
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.

Environmental Variables:
Device: Aries 2.5
BuildID: 20151103140850
Gaia: 06de78d2c61c084956640c480280ba518b2fe29f
Gecko: 59a6ad6a921f4809dfc37d943d765300c65721e5
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.5) 
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
QA Whiteboard: [QAnalyst-Triage?][failed-verification]
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage?][failed-verification] → [QAnalyst-Triage+][failed-verification]
Flags: needinfo?(jmercado)
I can reproduce the same issue in comment 26. In the mean time, I used Web IDE to inspect the running Clock app process, and tried:

new Date().toString();
new Date().toLocaleString();
new Date().toLocaleFormat();
new Date().getTimezoneOffset();
Intl.DateTimeFormat(navigator.languages, {hour: 'numeric',minute: 'numeric'}).format(Date.now());
mozIntl.DateTimeFormat(navigator.languages, {hour: 'numeric',minute: 'numeric'}).format(Date.now());

All produced correct outputs, which means the app should be able to get correct date & time from Gecko, no matter which method it used. 

Further digging shows the issue should be caused by the DateTimeFormat cache in Gaia [1] which the digital clock uses [2]. A DateTimeFormat instance is associated to a specific timezone on create, so if the object is not re-created on timezone changes, it keeps outdated timezone.

I think we should re-open bug 1210190 to track on it, since it's a different issue in Gaia.

[1] https://github.com/mozilla-b2g/gaia/blob/a9399f148859dc9dce73c4f2a2fd7653388aa9bc/shared/js/intl_helper.js#L22
[2] https://github.com/mozilla-b2g/gaia/blob/a9399f148859dc9dce73c4f2a2fd7653388aa9bc/apps/clock/js/panels/alarm/clock_view.js#L167
> Further digging shows the issue should be caused by the DateTimeFormat cache in Gaia [1] which the digital clock uses [2]. A DateTimeFormat instance is associated to a specific timezone on create, so if the object is not re-created on timezone changes, it keeps outdated timezone.

Oh! Great catch! What event do we have that indicates timezone change? I'll use it to reset formatters the same way as we do for `timeformatchange` and `languagechange`.
Ok, I see 'moztimechange' and tried to plug it in, but Intl doesn't seem to respond to those changes.

I was testing on flame-kk build from today:

1) Timezone is America/Los Angeles
2) Launching Settings
3) (new Date()).getTimezoneOffset(); // 480 - CORRECT
4) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 4:17:10 PM" - CORRECT
8) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 16:17:55 2015" - CORRECT
5) Changing timezone manually to America/New York via Settings app
6) (new Date()).getTimezoneOffset(); // 300 - CORRECT
7) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 4:18:29 PM" - INCORRECT
8) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 19:18:54 2015" - CORRECT
9) Killing the app manually and restarting
10) (new Date()).getTimezoneOffset(); // 300 - CORRECT
11) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 7:21:40 PM" - CORRECT
12) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 19:22:15 2015" - CORRECT

In other words - it seems that Intl still doesn't react to timezone change until app restart. Reopening
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I filed bug 1221817 to make our cached Intl objects reset on moztimechange in the meantime.
While you're at it, could you take a look at related bug 1188791? Thanks.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #30)
> Ok, I see 'moztimechange' and tried to plug it in, but Intl doesn't seem to
> respond to those changes.
> 
> I was testing on flame-kk build from today:
> 
> 1) Timezone is America/Los Angeles
> 2) Launching Settings
> 3) (new Date()).getTimezoneOffset(); // 480 - CORRECT
> 4) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 4:17:10
> PM" - CORRECT
> 8) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 16:17:55 2015" -
> CORRECT
> 5) Changing timezone manually to America/New York via Settings app
> 6) (new Date()).getTimezoneOffset(); // 300 - CORRECT
> 7) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 4:18:29
> PM" - INCORRECT
> 8) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 19:18:54 2015" -
> CORRECT
> 9) Killing the app manually and restarting
> 10) (new Date()).getTimezoneOffset(); // 300 - CORRECT
> 11) (new Date(Date.now())).toLocaleString('en-US'); // "11/4/2015, 7:21:40
> PM" - CORRECT
> 12) (new Date(Date.now())).toLocaleFormat(); // "Wed Nov  4 19:22:15 2015" -
> CORRECT
> 
> In other words - it seems that Intl still doesn't react to timezone change
> until app restart. Reopening

Checked on Flame-kk but can't reproduce the same issue (see the attached Web IDE screenshot). Could you do me a favor to check if the bionic revision is the same as mine by using the following command in your B2G directory?

> flame-kk$ git -C bionic rev-parse HEAD
> 3e85c4683c121530c1c3a48c696a569bf5f587e2
I used taskcluster build flame-kk-eng from today. It's sources.xml has this entry:

<project name="platform_bionic" path="bionic" remote="b2g" revision="3e85c4683c121530c1c3a48c696a569bf5f587e2"/>
Build number in settings is 20151104.112451
Build identifier is 20151104113939
Gaia commit: 2015-11-05 00:28:19 20f980d1

I can try to build my custom build and see if I still have this problem.
Actually, I can't build flame locally (Mac OS 10.11 is not supported by our build system)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #37)
> Actually, I can't build flame locally (Mac OS 10.11 is not supported by our
> build system)

I'll try OS X later, in the meantime could you provide me the taskcluster link of your build so I can also try the same build you used locally?
(In reply to Samael Wang [:freesamael][:sawang] from comment #38)
> (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #37)
> > Actually, I can't build flame locally (Mac OS 10.11 is not supported by our
> > build system)
> 
> I'll try OS X later, in the meantime could you provide me the taskcluster
> link of your build so I can also try the same build you used locally?

Sure. It's here: https://tools.taskcluster.net/index/artifacts/#gecko.v1.mozilla-central.latest.linux.flame-kk-eng/gecko.v1.mozilla-central.latest.linux.flame-kk-eng.opt
btw. I just landed the patch in bug 1221817 which means that IntlHelper is now reacting to `moztimechange` events. Since I can't get Flame to work properly, I can't test it, but if you have a build where Intl reacts properly to timezone change, your experience should improve drastically :)
Samael: I downloaded latest build from taskcluster for Aries-kk and I still see the same bug. Unless the fix is lower level and the flash from taskcluster build doesn't cover your fix, it seems that it's not fixed on either Aries or Flame :(
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #41)
> Samael: I downloaded latest build from taskcluster for Aries-kk and I still
> see the same bug. Unless the fix is lower level and the flash from
> taskcluster build doesn't cover your fix, it seems that it's not fixed on
> either Aries or Flame :(

I wasn't able to download the build yesterday due to TaskCluster permission issue. I just get able to try it and yes I can reproduce the same issue on flame-kk with TC's build.

It's weird it also make some strange sound on my flame-kk as if some kind of accessibility feature...? I heard a female voice saying "FT", "seven" or something.

Anyway I'm taking a look on why it behaves differently from my local build.
> It's weird it also make some strange sound on my flame-kk as if some kind of accessibility feature...? I heard a female voice saying "FT", "seven" or something.

That's the new TTS voice assistant in Firefox OS (Vaani) :) It does start with FTU. Last week it was saying a whole sentence, now it chops off on the first word. I assume they're working on it.

Anyway, I hear the same :)
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #41)
> Samael: I downloaded latest build from taskcluster for Aries-kk and I still
> see the same bug. Unless the fix is lower level and the flash from
> taskcluster build doesn't cover your fix, it seems that it's not fixed on
> either Aries or Flame :(

Turns out my local gecko was outdated, so it's a regression issue. Bisecting points me to ee397c027df9 [1] eventually. I also tried the marionette test case [2] on emulator-x86-kk to confirm the regression. 

Jeff, could you take a look on the symptom mentioned in comment 30?

BTW, Zibi, I tried building flame-kk on Mac OS X 10.11 today and it worked well. I've set up my Mac for a long time so I can't remember what I have done before, but if you're unable to build flame-kk with the instructions on MDN, you might consider file a bug of it, maybe there are some missing pieces of documentation.

[1] https://hg.mozilla.org/mozilla-central/rev/ee397c027df9
[2] https://hg.mozilla.org/mozilla-central/rev/ef950ac3d341
Flags: needinfo?(jwalden+bmo)
> BTW, Zibi, I tried building flame-kk on Mac OS X 10.11 today and it worked well.

It may actually just be problem with XCode 7.1 - I filed bug 1222305 and there's a workaround that I used successfully! Thanks.
I confirm that change from bug 1208808 regressed this bug.

With the patch from bug 1208808 reverted the timezone changes are properly reflected on lockscreen, statusbar in settings and clock apps.
Samael, I talked to Waldo on IRC today and he says that he's swamped with some es6 semantics. Would you be willing to take a look at the regression? I suspect that while trying to lazy load stuff Waldo's patch in bug 1220693 just didn't invalidate cache in the right place.
Flags: needinfo?(sawang)
We have noticed that manually setting the time does not change the time on the device until a restart. Is this tied to this issue currently being tracked Zibi?
Flags: needinfo?(gandalf)
I do not see this problem on master. Is that 2.5? There was a bug (bug 1221817) that was fixed that made us react to time changes.

It also makes Gaia react to timezone changes, but unfortunately this bug makes us recreate the DateTime object with old timezone so that seems like the timezone doesn't change.

If it's 2.5, I just requested that patch to land in 2.5. If it's master, I'd need STR.
Flags: needinfo?(gandalf)
So, I just landed the moztimechange for IntlHelper in 2.5, so now it should nicely update on time change in 2.5 as well, but will get stuck on timezone change due to this regression.
Flags: needinfo?(ktucker)
I can no longer reproduce the status bar time not changing when manually changing the time in settings. However, i noticed that when manually changing the time in settings, the status bar time will change but not to the time it was set to on 2.6. In 2.5, these times mirror each other so we wrote this up. See bug 1224401.
Flags: needinfo?(ktucker)
> However, i noticed that when manually changing the time in settings, the status bar time will change but not to the time it was set to on 2.6. In 2.5, these times mirror each other so we wrote this up.

That's probably incidental. Both (2.6 and 2.5) are reacting to time changes, but not to timezone changes. If you change timezone, your time will be off until you reset the phone. And the reason for this is this bug's regression.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #47)
> Samael, I talked to Waldo on IRC today and he says that he's swamped with
> some es6 semantics. Would you be willing to take a look at the regression? I
> suspect that while trying to lazy load stuff Waldo's patch in bug 1220693
> just didn't invalidate cache in the right place.

I'd love to help, but I'm also occupied recently in preparation of some Gecko's NGA support topics which we'll need to discuss during Mozlando work week. I might not be able to work on this or other timezone related issues anytime soon. If Jeff isn't available either, this may be pended for a while...
Flags: needinfo?(sawang)
Flags: needinfo?(jwalden+bmo)
Bug 1220693's patch was wrong in a glaringly stupid way, such that the time zone used by Intl would actually *never* change, rather than lazily change every JS::ResetTimeZone().  I've posted a patch that should fix the problem.
Also, if the user is changes the region and city in the FTU, the date will be way off and changing the date manually does not fix the issue.
> Also, if the user is changes the region and city in the FTU, the date will be way off and changing the date manually does not fix the issue.

This should be fixed with today's landing in bug 1220693. Let's start testing with tomorrow's build for any cases of date/time updates not being reflected in the UI.
I can confirm that on latest (20151124) builds for flame and aries I can no longer reproduce the bug and date/time changes and adjusts properly.
Status: REOPENED → RESOLVED
Closed: 9 years ago → 9 years ago
Resolution: --- → FIXED
That *also* means that we can finally start looking for any bugs related to time/date. If you see your time wrong (compared to what you set), timezone not updated, or time in two places not matching - it's a new bug.
(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #59)
> That *also* means that we can finally start looking for any bugs related to
> time/date. If you see your time wrong (compared to what you set), timezone
> not updated, or time in two places not matching - it's a new bug.

Woo! Any idea if this would affect bug 1221316? Maybe OTA is a different problem.
This issue is Verified Fixed on the latest Aries 2.6, Flame 2.6 and 2.5 builds.
Using the STR from comment 26, the Time is always consistent with the Status bar and the Clock app.

Environmental Variables:
Device: Aries 2.6
BuildID: 20151125131311
Gaia: 9eca89f04628c99226e0d18c15d5ae11b71af0cf
Gecko: 1835baed2a38429a3cc301d21778a113d3a9e7d8
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.6
BuildID: 20151125030226
Gaia: 37250b125e0db6966875d3b37b117f6d9b76cbc0
Gecko: 099f695d31326c39595264c34988a0f4b7cbc698
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 45.0a1 (2.6) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20151125122518
Gaia: 93b8bf2de3258c25199d97036c50a87667059148
Gecko: 913818c231658f959ce779ce2763ddb864024057
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a2 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Note: This does NOT also fix bug 1221316. The OTA Time issue is still occurring when running an OTA to the latest Flame 2.6 build.
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+][failed-verification] → [QAnalyst-Triage?]
status-b2g-v2.5: fixed → verified
status-b2g-master: --- → verified
Flags: needinfo?(jmercado)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmercado)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: