Restore datetime formatting to be sensitive to OS regional setting - use MozIntl

NEW
Assigned to

Status

Calendar
Internal Components
P2
normal
25 days ago
3 days ago

People

(Reporter: MakeMyDay, Assigned: Javi Rueda, NeedInfo)

Tracking

Lightning 5.7

Details

Attachments

(1 attachment)

(Reporter)

Description

25 days ago
Follow-up to bug 1229684 to restore the pervious behaviour of considering the OS regional settings for datetime formatting for Calendar once the last patch for that bug landed.

Meanwhile mozIntl is available do do this, unfortunately this is only available for chrome code and probably at least for email invitation preview dates/times we need some logic to mock this for consistency.

Nevertheless, for most of the use cases using

Services.intl.createDateTimeFormat(undefined, { dateStyle: "xxx", timeStyle: "xxx" });

in the datetimeformatter instead with xxx = long|medium|short (iirc) should do the trick.
(Reporter)

Updated

25 days ago
Depends on: 1229684
(Assignee)

Comment 1

24 days ago
.

Adding me to the CC list
(Assignee)

Comment 2

23 days ago
In bug 1229684 we were able to show dates and times in the format it was expected, but only in views. At least, when changing timezone in operating system settings, date and time formatting was adjusted acordingly. When changing the locale, date format was also changed, as far as I remember.

Then, what this bug is about is asking for the same to be done on code that doesn't format strings for chrome.

Could you provide some steps so developer could visually test changes?
Flags: needinfo?(makemyday)

Comment 3

17 days ago
Created attachment 8865365 [details]
Picture showing the problem

Comment 4

17 days ago
Oops, pressed "enter" too quickly. I'm using an en-US Daily but with an en-GB format locale configured on Windows. If Calendar used MozIntl, an en-US version would follow the en-GB locale settings and display 05/06/2017 for the 5th of June 2017. I also see 6 PM in the UI in some (not all) spots where it should be 18:00.

So Javi, to test this, use and en-US Daily and set your locale to en-GB and configure DD/MM/YYYY with 24h time.
Summary: Restore datetime formatting to be sensitive to OS regional setting → Restore datetime formatting to be sensitive to OS regional setting - use MozIntl
(Assignee)

Updated

16 days ago
Assignee: nobody → foss

Comment 5

16 days ago
Is this related to Bug 1350679?

Comment 6

16 days ago
I wasn't aware of bug 1350679. Not really related, I'd say, but part of the big date/time format rework. Bug 1350679 has a very limited scope, only few callers of toLocaleFormat() left:
https://searchfox.org/comm-central/search?q=toLocaleFormat&case=true&regexp=false&path=calendar

Comment 7

7 days ago
Thanks, Javi, for taking the bug. Looks like it's not a large patch this time:
https://hg.mozilla.org/try-comm-central/rev/612e36a37f41ca15b29e8ef6f87d29237e48d563

It would be great to have this completed before the next branch date, 2017-06-12, to go into TB 55 without uplifts. Also, en-US date/time display which is not taking any OS settings into account is really quite annoying to many Daily users like myself. So the sooner we can get this fixed, the better.
(Assignee)

Comment 8

7 days ago
Hi Jorg.

Yes. And that try-run was just a test, I didn't remove most of the code which wasn't run, in fact.

Final code will be even smaller, as most of the code for the past patch for bug 1229684 will be provided by mozIntl instead :)

(Removing the needinfo for :makemyday as that was answered by a previous comment)
Flags: needinfo?(makemyday)

Comment 9

6 days ago
Hello,

I use Windows 10 x64, French-Canadian version (fr-CA).

As a fallout of bug 1344594, the date format has changed in Thunderbird. TB v. 55 (nightly from 2017-05-19) has fixed the issue for Thunderbird itself but not for Lightning.

So in Thunderbird's list of messages, the date appears as "2017-05-17 à 23:00" (litteraly aaaa-mm-dd at HH:mm), which is much better than what happened with TB 53 and 54.

However, in the calendar (integrated Lightning), the date appears as "dd/mm/yyyy HH:MM" (ex.: 17/05/2017 18:30), whereas it previously appeared as "2017-05-17 23:00". It makes it a bit confusing, especially as I live in an environment where the U.S., European French and ISO notations are used.

BTW, the system configuration is "aaaa-mm-dd HH:mm".
(Assignee)

Comment 10

6 days ago
(In reply to Michel from comment #9)
> 
> As a fallout of bug 1344594, the date format has changed in Thunderbird. TB
> v. 55 (nightly from 2017-05-19) has fixed the issue for Thunderbird itself
> but not for Lightning.
> 

Calendar application is about time -both dates and time itself- so needs more granular control over dates and times, while Thunderbird doesn't need it.

> So in Thunderbird's list of messages, the date appears as "2017-05-17 à
> 23:00" (litteraly aaaa-mm-dd at HH:mm), which is much better than what
> happened with TB 53 and 54.
> 
> However, in the calendar (integrated Lightning), the date appears as
> "dd/mm/yyyy HH:MM" (ex.: 17/05/2017 18:30), whereas it previously appeared
> as "2017-05-17 23:00". It makes it a bit confusing, especially as I live in
> an environment where the U.S., European French and ISO notations are used.
> 

There are lots of places where Calendar is showing a date. Could you be more especific on where that date was showing, please? That way I could chack when testing the patch, although in a non-French build.

Bug 1229684 introduced that change and here we are going to ammend it. Nowadays there are lots of changes in the comm-central repo related to date and time formatting. Previous bug had to land because there was a problem that need to be fixed when building. That was fixed by 1229684.
Flags: needinfo?(michgagnon)
(Reporter)

Comment 11

4 days ago
Javi, sorry for not responding earlier, I have been off for some days. It seems you already got the instructions to prepare the environment to fix this.

Looking at your recent try push, you should stick with the use of _inTimezone to avaoid regressions and introduce the use of mozIntl therein, passing the the appropriate dtOptions in from the format* functions accordingly.

While this would be straight forward, have you already checked whether we need to work around the mozIntl restrictions for email invitation preview?
(Assignee)

Comment 12

3 days ago
(In reply to [:MakeMyDay] from comment #11)
> Javi, sorry for not responding earlier, I have been off for some days. It
> seems you already got the instructions to prepare the environment to fix
> this.
> 

Hi :) No problem.

> Looking at your recent try push, you should stick with the use of
> _inTimezone to avaoid regressions and introduce the use of mozIntl therein,
> passing the the appropriate dtOptions in from the format* functions
> accordingly.
> 

Yeah. That try-push was a test. Very very very dirty one. It showed that it wasn't working as expected in a different timezone and locale configuration than mine, which was what I was testing for.

My latest local patch has modified a little bit the code introduced in bug 1229684. I am using _inTimezone, but passing dateStyle instead in order to avoid timezone conversions. The fields which should be shown are provided by mozIntl, so that makes new code more compact.

Testing in my local system after changing system timezone to LA shows that it is working almost as expected.

What I am facing problems with is that the date formatting: although requesting the formatter to use day="2-digit", it is always using day:"number". That is making tests to fail. However, I think using 2-digit is mandatory, so I will keep working on it.

> While this would be straight forward, have you already checked whether we
> need to work around the mozIntl restrictions for email invitation preview?

No :/ :\ :/ :\ Steps to reproduce, please?
(Reporter)

Comment 13

3 days ago
You just need a received email invitation in your inbox and look at the dates/times in the invitation preview with different regional settings. I would expect mozIntl wouldn't apply the custom settings in that case.
You need to log in before you can comment on or make changes to this bug.