[RFC] Intent to regress timezone switching

[Zibi Braniecki]

Hi all!

tl;dr - I am considering temporarily regressing timezone switching in Gaia master. If that happens, we will have a short period when updating timezone will be reflected only after restarting B2G.

We want all master testers to be aware of that, and if you see a reason for which we should absolutely not do this, please, let me know.

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

Long explanation:

We are moving away from our aged l10n_date.js shim to shiny new Ecma 402, a.k.a Intl API for date, time, currency and number formatting[0].

The new API is awesome. It lets us be more consistent, it's faster, it's more powerful, it lowers the burden on our localizers and simplifies our code.
It also allows us to remove the main source of mozL10n.get uses and that in turn brings us closer to make it possible for apps to migrate to new L10n API.

There is one small issue. Our Intl API uses ICU library which has a bug[1]. They didn't expect that timezone may change while ICU is initialized so they designed the whole API around the idea that timezone is immutable.

The result is that today we are sitting for almost two months here with a flock of refactoring patches for System, Homescreen, Lockscreen, SMS, Dialer, Communications and Settings that will make our code cleaner, faster and work better for different locales including RTL.

The bug is assigned and we are getting close to fixing the ICU bug, but we still need more time. We can keep waiting with all those patches, or we can accept the regression and unblock all the work.

That's also important because if there's any other bug with the new API we will not find it until we start landing. The later we land, the less time we'll have to discover those bugs.

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

Bottom line is, that I believe that we have all the stakeholders aligned and we know we can fix the ICU bug in time, so I believe the risk of us not being able to fix ICU and having to backport or the refactoring is close to zero. I'm willing to take that risk as a module owner.

But since we don't have an established practice for introducing known temporary regression, I prefer to be overcautious and make sure that everyone affected is aware and has a chance to veto this decision.

Thanks,
zb.

[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1170963
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172609

[Zibi Braniecki]

On Wednesday, July 22, 2015 at 1:31:06 PM UTC-7, Zibi Braniecki wrote:
> Bottom line is, that I believe that we have all the stakeholders aligned and we know we can fix the ICU bug in time, so I believe the risk of us not being able to fix ICU and having to backport or the refactoring is close to zero.

*and having to revert all of the refactoring is close to zero.

zb.

p.s. Since I got this question - this is not related to our devices not keeping the time right. It's only about how we format the date that the system has using the old timezone after you switch the timezone. Nothing else changes.

[Michael Henretty]

On Wed, Jul 22, 2015 at 1:42 PM, Zibi Braniecki <zbigniew....@gmail.com> wrote:

p.s. Since I got this question - this is not related to our devices not keeping the time right. It's only about how we format the date that the system has using the old timezone after you switch the timezone. Nothing else changes.

Can you be more explicit here? If we land your patch (bug 1172699 I believe?), what exactly will the user see (or not see) when they change timezones? I think the biggest impact will be on QA since it will probably break smoketests, but we should know the entire impact since it could effect foxfooders.

Also Tedders, do you have an idea of how much longer bug 1172609 will take?

[Zibi Braniecki]

On Wednesday, July 22, 2015 at 2:33:55 PM UTC-7, Michael Henretty wrote:
> On Wed, Jul 22, 2015 at 1:42 PM, Zibi Braniecki <zbigniew....@gmail.com> wrote:
> p.s. Since I got this question - this is not related to our devices not keeping the time right. It's only about how we format the date that the system has using the old timezone after you switch the timezone. Nothing else changes.
>
>
> Can you be more explicit here? If we land your patch (bug 1172699 I believe?), what exactly will the user see (or not see) when they change timezones? I think the biggest impact will be on QA since it will probably break smoketests, but we should know the entire impact since it could effect foxfooders.

Absolutely. Thanks for asking!

The difference will be that some time labels will show time in the *old* timezone, while other labels will show time in the *new* timezone.

It will only happen if you change timezone and will disappear after you restart the device.

The reason for that is that some time labels will use the old mechanism (based on l10n_date.js) which does follow timezone changes, while others will use the Intl API which has the bug.

Initially, I intent to transform Statusbar time icon and Lockscreen time label. Then, depending on reviews I will transition Settings, SMS, Dialer and Communications.

zb.

[Fred Lin]

Finally we got Intl API on FxOS!

Does it support customized 24/12hr format?

2015-07-23 4:30 GMT+08:00 Zibi Braniecki <zbigniew....@gmail.com>:

Hi all!

tl;dr - I am considering temporarily regressing timezone switching in Gaia master. If that happens, we will have a short period when updating timezone will be reflected only after restarting B2G.

We want all master testers to be aware of that, and if you see a reason for which we should absolutely not do this, please, let me know.

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

Long explanation:

We are moving away from our aged l10n_date.js shim to shiny new Ecma 402, a.k.a Intl API for date, time, currency and number formatting[0].

....

[Zibi Braniecki]

On Wednesday, July 22, 2015 at 6:55:59 PM UTC-7, Fred Lin wrote:
> Finally we got Intl API on FxOS!

Yesss!!

> Does it support customized 24/12hr format?

Yes and no. Depending on which part you're asking about :)

Yes, as in, Intl API provides hour12 config option that defines which time format it used.

No, as in, the information of which format we are using comes from navigator.mozHour12 (I'm looking for a dev who'd write a patch to move it to platform so that we don't need Settings privileges for each app[1]).

Yes, as in, if navigator.mozHour12 is undefined (we should extend Settings to allow for "Default" value) then Intl API will use the right one for the given locale.

Cheers,
zb.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1172732

[Anthony Ricaud]

I have no opinion on whether this should land or not. If it does land
though, a short explanation + link in the Timezone settings would make
it easier for everyone to know what to expect until the ICU bug is fixed.

[Johan Lorenzo]

+qa-b2g

Thanks for calling this out, Zibi.

I think it's more prudent to leave QA test these patches before they land, so we'd prevent them to break the smoketests. Please NI me on each bug you would like to get tested. I'll bring this topic up in the next QA stand up (in 8 hours).

Cheers,

Johan

On Thu, Jul 23, 2015 at 10:09 AM, Anthony Ricaud <ant...@ricaud.me> wrote:

I have no opinion on whether this should land or not. If it does land though, a short explanation + link in the Timezone settings would make it easier for everyone to know what to expect until the ICU bug is fixed.

On 22/07/15 22:30, Zibi Braniecki wrote:

_______________________________________________
dev-gaia mailing list
dev-...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-gaia

[Zibi Braniecki]

On Thursday, July 23, 2015 at 2:10:01 AM UTC-7, Johan Lorenzo wrote:
> +qa-b2g
>
>
> Thanks for calling this out, Zibi.
>
> I think it's more prudent to leave QA test these patches before they land, so we'd prevent them to break the smoketests. Please NI me on each bug you would like to get tested. I'll bring this topic up in the next QA stand up (in 8 hours).

Cool! Thanks!

We have now three patches with reviews that I'm intending to land once all stakeholders give a go-ahead.

The areas are (in the order):

Statusbar Time icon: https://bugzilla.mozilla.org/show_bug.cgi?id=1172699
Lockscreen time/date: https://bugzilla.mozilla.org/show_bug.cgi?id=1172621
SMS: https://bugzilla.mozilla.org/show_bug.cgi?id=1171206

Johan, with the first two I'm only waiting for QA approval now.

zb.

[Zibi Braniecki]

Aand, all three patches landed.

Three affected areas are:

1) Status bar time icon
2) Lockscreen time/date
3) SMS times and dates

The regression I mentioned in my original post is visible when you modify the timezone. There are a couple things that can be noticed:

a) Time may be off. We know we have problems with internal clock, but this is different. Time will be consistent, but in your old timezone.
b) Time may be different between affected areas and non-affected areas. The time in Settings will use the new timezone, while time icon in the statusbar will use the old one.
c) It may be that you will see amPm portion in hour12 format when you shouldn't. That's an artifact of how we workaround limitations of our datetime API combined with the timezone switch regression.

All three things may only happen when you change timezone and should go away after you reboot your phone.

I'll work with Ted to get the timezone switch regression fixed as soon as possible now.

On the bright side - you can start using Intl API in your code :) It's awesome!

zb.