1421910 - v57.0 forcing US date format

Status: RESOLVED INACTIVE

(Core :: Internationalization, defect, P3)

Description

[Chris King]

User Agent: Mozilla/5.0 (Windows NT 6.2; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171112125346

Steps to reproduce:

accessing page with html form with input type of "date".

example:
<input type="date" name="StartDate" value="2017-12-04" size="10" maxlength="10">


Actual results:

v57.0 is now formatting the "2017-12-04" as a dropdown calendar object and displaying the date as "12 / 04 / 2017"


Expected results:

date should display as "04 / 12 / 2017" at the computer is set to use european date format (dd/mm/yyyy)

Comment 2

[Chris King]

Disagree that this is a duplicate of 1337069

as this problem has only been introduced in the latest update
while 1337069 is unix specific and months old

Comment 3

[Chris King]

Do you at least have a workaround that will work with Windows ?

Comment 4

[Matthias Versen [:Matti]]

This behavior change is from bug 1366188

Comment 5

[Makoto Kato [:m_kato]]

What is Firefox UI locale?  If you use English version, it should be US format.

Comment 6

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

Also, can you check that if the behavior is correct in Nightly?

Comment 7

[Chris King]

(In reply to Makoto Kato [:m_kato] from comment #5)
> What is Firefox UI locale? 

I have no idea how to set this, or lookup the UI Locale.
Please provide instructions.

> If you use English version, it should be US format.

I have no idea how you came to this assumption.
There are more English speaking countries in the world that
use the European date format than there are that use the US
date format. You can not assume any date format from the 
English language.

Comment 8

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

> I have no idea how to set this, or lookup the UI Locale.
> Please provide instructions.

In Firefox 58 (currently in beta) or 59 (currently in Nightly) you can just open `about:support`, scroll down and at the bottom you will see a list of entries related to internationalization and localization. Copy and paste it here.

Unfortunately, we didn't add this feature until 58 so for 57, you need to open browser console and type `Services.locale.getRequestedLocales()` and `Services.locale.getAvailableLocales()`.

> You can not assume any date format from the English language.

We provide Firefox in many locales. Locale is a combination of a language, script and region. When you download Firefox in "en-US" you're downloading American English Firefox.

You can also download British English Firefox (en-GB) etc.

We do not provide all combinations of languages and regions yet, but we do some smart things around matching your OS regional preferences to Firefox internationalization.

Final touches to that feature landed in Firefox 58, so it would be very helpful for me if you could download Nightly from http://nightly.mozilla.org/ and see if the problem is fixed in it already.

If it is not, we can investigate further!

Comment 9

[Chris King]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #8)

> In Firefox 58 (currently in beta) or 59 (currently in Nightly) you can just
> open `about:support`, scroll down and at the bottom you will see a list of
> entries related to internationalization and localization. Copy and paste it
> here.
> 
> Unfortunately, we didn't add this feature until 58 so for 57, you need to
> open browser console and type `Services.locale.getRequestedLocales()` and
> `Services.locale.getAvailableLocales()`.

Sorry, but I am only a user of the production line of releases
(which is where I am reporting the bug from)

> We provide Firefox in many locales. Locale is a combination of a language,
> script and region. When you download Firefox in "en-US" you're downloading
> American English Firefox.
> 
> You can also download British English Firefox (en-GB) etc.
> 
> We do not provide all combinations of languages and regions yet, but we do
> some smart things around matching your OS regional preferences to Firefox
> internationalization.

I am based in Australia and I don't believe that you have an en-AU version.
Australia (and New Zealand) use a mix of GB and US conventions in localisation
and so while en-GB may fix a date format, it may break other things
such as currency symbols.

To me, it seems strange for firefox to try and implement its own localisation
settings when windows has a suite of functions that provide details on 
date format, time formats, currency symbols, thousands separators, decimal
point symbol, etc

> Final touches to that feature landed in Firefox 58, so it would be very
> helpful for me if you could download Nightly from
> http://nightly.mozilla.org/ and see if the problem is fixed in it already.

I am prepared to download the nightly build into a VM over the weekend to 
provide the feedback

Comment 10

[Matthias Versen [:Matti]]

This is not fixed in the nightly. I'm using the en-us nightly with a german OS+german date format set in the OS but I still see the US date format.

I confirmed this bug report because I would expect that Firefox uses the OS settings for the date format as in the past 
Thunderbird and Seamonkey are using as example the OS setting for the date format. 
-> http://kb.mozillazine.org/Date_display_format

>I am based in Australia and I don't believe that you have an en-AU version.
We have en-GB, en-US,en-ZA on the server ( http://ftp.mozilla.org/pub/firefox/releases/57.0/win64/ ) but not en-AU

Comment 11

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

> To me, it seems strange for firefox to try and implement its own localisation
settings when windows has a suite of functions that provide details on 
date format, time formats, currency symbols, thousands separators, decimal
point symbol, etc

Understandably. That's a pretty complex topic. If you want to dive deeper, please, take a look at bug 1366134 - warning, that's a lot of reading :)

Anyway. I do believe that the particular case of en-US Firefox and en-AU Windows matching is solved in Firefox 58. Since you can't try it, and there's no chance we will be able to backport the changes back to 57, the only solution I believe is to wait until 58 becomes stable for you to verify that.

> I'm using the en-us nightly with a german OS+german date format set in the OS but I still see the US date format.

That's a different issue. We do match the regional preferences when the language matches (which is the scenario reported in this bug between en-US and en-AU), but we do not match when languages don't align (which is the case between en-US Firefox and de-DE OS).

> I confirmed this bug report because I would expect that Firefox uses the OS settings for the date format as in the past 
Thunderbird and Seamonkey are using as example the OS setting for the date format. 

There's a preference that allows you to force Gecko to use your OS regional preferences locale - go to about:config and switch `intl.regional_prefs.use_os_locales` to true.

I believe Thunderbird has a Preference checkbox for that as well.

If you care to learn more about the complex issues involving cross-locale matching when it comes to internationalization and localization, see bug 1366134 for details.

====


I'll leave this bug open until the reporter has a chance to verify if this is fixed in Firefox 58.

Comment 12

[Jorg K (CEST = GMT+2)]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #11)
> I believe Thunderbird has a Preference checkbox for that as well.
We do: Tools > Options, Advanced, General, Date and Time Formatting ;-)

Comment 13

[Chris King]

Attachment: Different behaviour on windoes 7 and 8

Windows 7 and 8 are behaving differently even though both PC's have the same region settings and both running the same version of FireFox - v57.0.1 (64 bit)

Comment 14

[Chris King]

Attachment: Region settings

Region settings are the same on both Windows 7 and 8 PC's

Comment 15

[Chris King]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #8)
> Final touches to that feature landed in Firefox 58, so it would be very
> helpful for me if you could download Nightly from
> http://nightly.mozilla.org/ and see if the problem is fixed in it already.

Zibi, after seeing the behaviour of windows 7 and 8 (above) I realised that installing into a VM will not help much
so I installed the Nightly (59.0a1) build onto the problematic Windows 8 PC and I can report that:
* It is now displaying the date in dd/mm/yyy format
* The calendar object is still starting the week on Sunday (but should be Monday)

> In Firefox 58 (currently in beta) or 59 (currently in Nightly) you can just open
> `about:support`, scroll down and at the bottom you will see a list of entries related
> to internationalization and localization. Copy and paste it here.

This is actually under "help > troubleshooting information"
the "Internationalization & Localization" details are as follows

Internationalization & Localization
Application Settings
Requested Locales           ["en-US"]
Available Locales              ["en-US"]
App Locales        ["en-US"]
Regional Preferences      ["en-AU"]
Default Locale    "en-US"
Operating System
System Locales ["en-US"]
Regional Preferences      ["en-AU"]

Comment 16

[Chris King]

just tried the beta (58.0b8) too and got the same results as the daily (59.0a1)

Comment 17

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

> * It is now displaying the date in dd/mm/yyy format

That's great to hear!

> * The calendar object is still starting the week on Sunday (but should be Monday)

Should it?

The CLDR (Unicode database for international data) defines first day of the week for AU as "Sunday" - https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/weekData.json#L73

If you believe they're wrong we should collect some data on that and file an issue against CLDR.

Comment 18

[Chris King]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #17)

> Should it?
> 
> The CLDR (Unicode database for international data) defines first day of the
> week for AU as "Sunday" -
> https://github.com/unicode-cldr/cldr-core/blob/master/supplemental/weekData.
> json#L73
> 
> If you believe they're wrong we should collect some data on that and file an
> issue against CLDR.

Well looking at the attached "Different behaviour on windoes 7 and 8" screenshots, 
it is either wrong in Windows 7 or it is wrong in Windows 8 behaviour.
* Windows 7 shows the week beginning on Monday (which matches locale settings of Windows)
* Windows 8 shows the week beginning on Sunday (which doe not match the locale)

Comment 19

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

(In reply to Chris King from comment #18)
> Well looking at the attached "Different behaviour on windoes 7 and 8"
> screenshots, 
> it is either wrong in Windows 7 or it is wrong in Windows 8 behaviour.
> * Windows 7 shows the week beginning on Monday (which matches locale
> settings of Windows)
> * Windows 8 shows the week beginning on Sunday (which doe not match the
> locale)

Can you clarify this statement please? What do you mean by "which does not match the locale"? As I said, CLDR has en-AU firstDay as Sunday.

That means, that if on Windows 8 you see the week beginning on Sunday, then the behavior on Windows 8 matches the expected behavior.

I'm not sure why this would work differently on Windows 7, but maybe the API we're using now wasn't properly populated back then?

Either way, the behavior on Windows 8 and Windows 10 is intended and aligned with the data we have from CLDR.

Unless this data is wrong, I'm not sure if there's anything else actionable here.

Comment 20

[Chris King]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #19)
> Can you clarify this statement please? What do you mean by "which does not
> match the locale"? As I said, CLDR has en-AU firstDay as Sunday.

I have no intention of challenging the standard, but as far as standards go
I have little faith in this one. Picking the day that a week should start on
is highly subjective ... hence why windows allow users to pick their own
preference.

> Unless this data is wrong, I'm not sure if there's anything else actionable
> here.

Agree, I just need to wait for v58 and things will greatly improve for the
issue that I have logged

thanks

Comment 21

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

> Picking the day that a week should start on
is highly subjective ... hence why windows allow users to pick their own
preference.

Actually, this is potentially actionable!

We currently look into OS preferences for date/time formats, but we don't look into them for first day of the week.
I filed bug 1422874 for that.

Comment 22

[Chris King]

(In reply to Zibi Braniecki [:gandalf][:zibi] from comment #21)
> We currently look into OS preferences for date/time formats, but we don't
> look into them for first day of the week.
> I filed bug 1422874 for that.

thanks for that

Comment 24

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

All that is left here is the first day of the week os lookup handled in bug 1422874. Reopen this one if needed.