1356403 - Replace ECMA402 toLocaleDateString with mozIMozIntl

Status: RESOLVED DUPLICATE of bug 1346549

(MailNews Core :: Backend, enhancement)

Description

[Jorg K (CEST = GMT+2)]

+++ This bug was initially created as a clone of Bug #1332351 +++

We should follow bug 1354445
https://hg.mozilla.org/mozilla-central/rev/79673e659b31
and use Services.intl.createDateTimeFormat() for date/times shown in chrome.

There are only a few:
mail/base/content/glodaFacetVis.js
mail/components/addrbook/content/abCardViewOverlay.js
mailnews/base/util/templateUtils.js

Yes, my fault, I was in a rush to get bug 1332351 landed but now something better has arrived. No harm done in changing three call sites.

Comment 1

[Jorg K (CEST = GMT+2)]

Attachment: WIP: 1356403-mozIMozIntl.patch

First attempt to use mozIMozIntl.

This works fine if the date I want to format has a year.

Zibi: Does that patternOption work? Can I format just day and month. So I'd like to see January 15 for en-US and 15 January for en-GB for example.

If I supply the pattern option, I get, for example, 6/24/2016 which even ignores the en-GB locale I'm using. It doesn't seem to work at all.

Comment 2

[Frank-Rainer Grahl (:frg)]

Seems the patch for mail/components/addrbook/content/abCardViewOverlay.js will be the same for 
suite/mailnews/addrbook/abCardViewOverlay.js. The only occurence of toLocaleDateString in suite. Will watch this bug and adapt it when finished.

Comment 3

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

Comment on attachment 8875825 [details] [diff] [review]
WIP: 1356403-mozIMozIntl.patch

Hi Jorg,

The patch looks good except that we do not allow for patternOption just yet.

There's a debate over the merit of doing that. If you want a consistent "dd MMMM", you should just use `${date.getDay()} ${date.getMonth()}`.

If you want it to be locale dependent I think you should use mozIntl and {month: "long", day: 'numeric'}.

Comment 4

[Jorg K (CEST = GMT+2)]

Maybe I haven't made the requirement clear enough.

We have two sorts of birthdates: Fully qualified ones, day, month, year, so I use mozIntl to display them.

Birthdays where the person hasn't disclosed their age, so we only know day and month. This I also want to make locale dependent, but the current implementation always forces a year. Hence the idea to use a pattern, but that doesn't work.

If I use `${date.getDay()} ${date.getMonth()}` or similar, I get day and months in a fixed order, but I really need them locale dependent.

TB should ideally display:

en-US: 06/24/2000
       06/24
en-GB: 24/06/2000
       24/06

Comment 5

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

Ah, thanks!

This seems to work for me:

(new Date()).toLocaleString('en-GB', {'day': 'numeric', month: 'long'}); // 27 June
(new Date()).toLocaleString('en-US', {'day': 'numeric', month: 'long'}); // June 27

Does it look like a reasonable solution?

Comment 6

[Jorg K (CEST = GMT+2)]

I don't think so.

mozIntl will get the app locale and see whether it needs to take any OS setting into account. So my en-US app on a system with en-GB regional settings gives me 27/06/2017. Great.

But formatting date and months, I can only go
  (new Date()).toLocaleString(undefined, {'day': 'numeric', month: 'long'});
and then I get 06/27 since the app is en-US.

I really need a mozIntl version of toLocaleString() and I thought that's what the pattern option might do for me.

Comment 7

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

> I really need a mozIntl version of toLocaleString() and I thought that's what the pattern option might do for me.

The issue is that OS does not provide users with settings for date/time patterns for "dd MMMM". That's why we tie the patterns to styles (because OS provides styles). :(

And in this case, if you use en-US app, you should get en-US date time. If you want en-GB date time you should use en-GB app.

Comment 8

[Jorg K (CEST = GMT+2)]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7)
> And in this case, if you use en-US app, you should get en-US date time. If
> you want en-GB date time you should use en-GB app.
I disagree. The en-US app can perfectly format a full (birth)date to 27/06/2000 since it obeys the en-GB settings.
I don't see why a birthday without year should be formatted en-US as 06/27.

Maybe what I need to do is use mozIntl in both cases and then string replace/remove the (wrong fake) year when the year is unknown. I wonder for how many locales that's not going to work, like which locales don't use Arabic numerals for their years.

Comment 9

[Jorg K (CEST = GMT+2)]

I'll fix this as part of bug 1346549.

Comment 10

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

(In reply to Jorg K (GMT+2) from comment #8)
> (In reply to Zibi Braniecki [:gandalf][:zibi] from comment #7)
> > And in this case, if you use en-US app, you should get en-US date time. If
> > you want en-GB date time you should use en-GB app.
> I disagree. The en-US app can perfectly format a full (birth)date to
> 27/06/2000 since it obeys the en-GB settings.

That's not true, and it's part of the whole riddle where respecting OS prefs leads to a rabbit hole.

What we do is:
 - take the browsers locale (language and region)
 - look into OS and see if the language matches
 - if so, let OS provide us with the regional preferences

On an en-GB OS with en-US Gecko app it *looks* like we do "en-GB", but that's not true. We're en-US app, which is what the user chose, we just happen to take regional settings from the OS in several cases. Those may be GB settings, or custom values, we don't know.

But we are not "en-GB" product, and it seems like you're trying to make it one :)

> I don't see why a birthday without year should be formatted en-US as 06/27.

because the user installed en-US product.
 
> Maybe what I need to do is use mozIntl in both cases and then string
> replace/remove the (wrong fake) year when the year is unknown. I wonder for
> how many locales that's not going to work, like which locales don't use
> Arabic numerals for their years.

This will likely break in more than one way. You're the owner, you can do whatever you want, and I can only advise you against it :)

You're in en-US product. In all but a few selected cases, you will present US regional settings. In those few cases, we'll do some smart things which will mean that for dateStyle/timeStyle we can actually give a better result and it's unlikely we'll result in any mess, but almost everything else will be "US" in this product.
Including such a date as "dd MMMM" or unit display, or plural rules or terminology ("color" vs "colour" etc.)

If you try to slash the date/time pattern by hand to get what you think you want, you'll break multiple paradigms ("don't touch the result string") and likely introduce regressions for locales which don't fit (non gregorian calendars, RTL, non latin alphabets).
But the main problem is that you'll enter a rabit hole. You'll have to, from now on, keep going and slashing all "US" regional customizations to be "GB". Some of them we can pick from OS, others will go directly from ICU/CLDR. And you'll have to, in each case, decide, how it should work not just fro GB+US, but also for JO+DE, HE+FR, zh_CN+DE and so on.

Comment 11

[Jorg K (CEST = GMT+2)]

Don't worry, I'm doing
+        formatter = Services.intl.createDateTimeFormat(undefined,
+                      { month: "long", day: "numeric" });
over in bug 1346549 for the year-less birthday ;-)
I won't like it, but I can't do better without inviting a colony of rabbits.