1343768 - Library's dates doesn't use the operating system's date and time format

Status: RESOLVED FIXED

(Firefox :: Bookmarks & History, defect, P1)

Description

[Link]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170301030202

Steps to reproduce:

1. Change the time format on Windows to aaaa-MM-dd (Short date)
2. Open the library.
2. Select Views, Show columns and check "Added".



Actual results:

The date uses the mm/dd/aaaa format.


Expected results:

The date should be using the aaaa-mm-dd like Firefox 51.0.1.

Comment 1

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

This will get fixed with bug 1339650 which I intend to land next week. mozIntl.DateTimeFormat will respect OS preferences.

Comment 2

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

Oh, but the Library date/time formatting uses C++ API. How hard would it be to port this view to JS?

Comment 3

[Marco Bonardo [:mak]]

Nope, the Library views are in js http://searchfox.org/mozilla-central/rev/e844f7b79d6c14f45478dc9ea1d7f7f82f94fba6/browser/components/places/content/treeView.js#478

Comment 4

[Marco Bonardo [:mak]]

Btw, it was my understanding we wanted to respect the app locale settings and not the OS ones?

Comment 5

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

> Nope, the Library views are in js

Ah, then yes, bug 1339650 will give us an API that fixes it.

> Btw, it was my understanding we wanted to respect the app locale settings and not the OS ones?

App Language settings, yes. But we also want to respect OS regional preferences.

So, we take the language from the app (user has Firefox in `fr`, we show date in `fr`), but if the user also has defined hour12 in their regional preferences in the OS, we should show hour12 hourCycle.

That's what bug 1339650 is about.

Comment 6

[Nayuki]

Attachment: Library screenshot

The current date format looks like "3/8/2017, 11:59 PM".

The previous date format in Firefox 51 looked like "2017-03-08-Wed 23:59", which respected my preferences in the Windows regional settings.

Comment 7

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

Correct, as I said, this will be fixed by bug 1339650 unless your OS and your Firefox use different locales (say, your OS is in 'en' and your Firefox is in 'de').

No need to report "me too" anymore. We know about the bug, the fix will hopefully land this week :)

Comment 10

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

[Tracking Requested - why for this release]: Regression

@ Zibi Braniecki [:gandalf][:zibi] - Unfortunately the bug #bug 1339650 didn't fix this regression, as I'm still seeing only 12h AM/PM and month/day/year, instead of  year-month-day (or at least day month year) and 24h on Windows 7 (64bit) [PL] with latest Nightly (64bit) [en-US], like it's in my system settings.

Comment 11

[Marco Bonardo [:mak]]

it actually depends on bug 1354445 that makes use of bug 1339650

Comment 12

[Gerry Chang [:gchang]]

Track 54+/55+ as regression.

Comment 13

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

:Virtual - why are you adjusting the importance of this bug? Are you an owner or peer of the module?

Comment 14

[Liz Henry (:lizzard) (relman/hg->git project)]

Too late to fix this in 53. Looks like the main work for this is landing in 55 nightly but may not yet be finished.

Comment 15

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

I changed severity to "major", because it corresponds to "Major loss of function", which better describes what this regression bug is about.

Comment 17

[Marco Bonardo [:mak]]

It's not major, nothing critical breaks because of this, and while it's an horrible annoyance, it's unlikely to cause serious harm. We should fix it asap, and that's what we'll try to do. If it's impossible to fix it before 55, we'll take the hit, we shipped worse regressions in the last years, fwiw (not that it's a good justification by itself, just that it happens, we are humans, we make mistakes).

The path forward is unclear atm, while I'd accept any sort of hack that reverts to the previous situation, I'm not prone to accept workarounds that introduce further changes to the date format.

If anyone has code ideas to revert this without the need for backing out the whole localization work I'll be open to those, otherwise this is likely to be just fixed in 55 by bug 1354445.

Comment 18

[Marco Bonardo [:mak]]

(as a side note, please, be respectful, any intolerable behavior will be reported to Bugzilla admins)

Comment 19

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

I believe this is now fixed with bug 1354445 landing.

Please, reopen if needed.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

I'm assuming that the fix for this will be riding the trains.

Comment 21

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Reopening because the issue can still be reproduced.

Steps to reproduce:
0. Have operating system (Windows 8.1) in a language different from English (German, 24-hour format).
1. Launch en-US Nightly (20170412).
2. Open menu History > Show All History.
3. Add the Most Recent Visit column.
Actual result:
en-US date and time stamps (in 12-hour format) like 3/5/2017, 5:05PM
Expected result:
05.03.2017 17:05

Comment 22

[Marco Bonardo [:mak]]

See https://bugzilla.mozilla.org/show_bug.cgi?id=1354445#c18

Comment 23

[Marco Bonardo [:mak]]

(PS: you can use a localized German Nightly, :flod let me know we now have nightly for almost all locales)

Comment 24

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

Thank you for the link with the explanation in bug 1354445 comment 18.

Comment 25

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Marco Bonardo [::mak] from comment #17)
> It's not major
But even Zibi Braniecki [:gandalf][:zibi] by himself changed duplicate bug to "major" severity (after bug #1354339 comment #33),
but now we have P1 now, so it's also all good.

(In reply to Marco Bonardo [::mak] from comment #17)
> The path forward is unclear atm, while I'd accept any sort of hack that
> reverts to the previous situation, I'm not prone to accept workarounds that
> introduce further changes to the date format.
> 
> If anyone has code ideas to revert this without the need for backing out the
> whole localization work I'll be open to those, otherwise this is likely to
> be just fixed in 55 by bug 1354445.

We can also swap to using logical International Standard ISO 8601 for everyone, so yyyy-mm-dd hh:mm:ss (24h), but USA probably won't be happy about it and other won't probably notice this. ;)



I can still confirm this issue,
Firefox still not respecting the operating system hour and date format, like other software.
Is still MM/DD/YYYY 12h AM/PM, but should be yyyy-mm-dd 24h.

Also we shouldn't be using the long date (with names of day of the week and names of the month),
just the short date (only with digits),
so there won't be any problems for mixing localization etc. with it and problem will be solved.

Comment 26

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

> I can still confirm this issue,
> Firefox still not respecting the operating system hour and date format, like other software.
> Is still MM/DD/YYYY 12h AM/PM, but should be yyyy-mm-dd 24h.

What is your OS, what is your browser locale, what is your OS locale and what is your user os locale?

> Also we shouldn't be using the long date (with names of day of the week and names of the month),
> just the short date (only with digits),
> so there won't be any problems for mixing localization etc. with it and problem will be solved.

This would not solve the problem. The variety of localization formats, numerical systems and directionalities is not solvable with an ISO date time format.

Comment 27

[foxpup]

This problem is still present with version 68.0 and I'm running Ubuntu 18.04. Perhaps most of the developers are using the goofy DD/mm/YYYY format over in Europe and don't care but the rest of us who find that "feature" confusing and annoying. When is the real fix going to happen? ...need to reopen and actually take the matter seriously. I am aware of no effective workaround.