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)

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

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

This behavior change is from bug 1366188

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

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

(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.

> 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!

(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

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

> 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.

(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 ;-)

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)

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

(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"]

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

> * 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.

(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)

(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.

(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

> 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.

(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