If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Driver date in about:support should be displayed YYYY-MM-DD (ISO 8601)

REOPENED
Unassigned

Status

()

Core
Graphics
REOPENED
7 years ago
6 years ago

People

(Reporter: flod, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Created attachment 470384 [details]
Driver date with different format in device manager (it) and about:support (en-US)

Information about the graphic card was added in bug 586046, but right now the driver date is displayed using en-US format (mm-dd-yyyy), while it should be displayed as a localized date (for example, in Italian, dd-mm-yyyy).

I'm opening this bug in the same component of bug 586046, I don't know if it should be moved to Firefox-General or similar.
This value comes straight from the registry. I don't think we want to write code to format it differently based on locale - it's not really meant for users to parse, but rather people diagnosing graphics issues, and modifying the value from the registry could lead to the information being misinterpreted.

Comment 2

7 years ago
I agree with Gavin.
(Reporter)

Comment 3

7 years ago
I still think that a localized date makes more sense in that context. However, if I can read correctly the code, that "date" is passed originally as a string, not as a date, so it could be non trivial to change its format.

Since other localizers should be listening to this bug, I'd like to read what they think about it.
(In reply to comment #1)
> This value comes straight from the registry. I don't think we want to write
> code to format it differently based on locale - it's not really meant for users
> to parse, but rather people diagnosing graphics issues, and modifying the value
> from the registry could lead to the information being misinterpreted.
The question is who is these "people diagnosing graphics issues"?
If graphic info section intended to be posted in Bugzilla for Mozilla developers, then en-US date notation is fine.
If graphic info section intended to posted on support forums by people seeking help with D2D/D3D9 issues, then en-US date notation is very counterintuitive.
If conversion of en-US date notation to localized date notation is not trivial, then ISO 8601 date format (http://en.wikipedia.org/wiki/ISO_8601#Calendar_dates) should be used, it's kind of standart for date representation.

Updated

7 years ago
Blocks: 594464

Comment 5

7 years ago
As far as I'm concerned, everything should be YYYY-MM-DD (ISO 8601) everywhere. It's the only non-ambiguous format and it sorts correctly in lists.
Blocks: 367596
No longer blocks: 594464
Version: unspecified → Trunk

Updated

7 years ago
Summary: Driver date in about:support should be displayed according to locale settings → Driver date in about:support should be displayed according to locale settings or ISO 8601
(In reply to comment #4)
> The question is who is these "people diagnosing graphics issues"?

My assertion is that they're people that can handle dealing with the format that the original data is in (in the registry), regardless of what language they speak. For the most part, that will be Mozilla developers.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX

Comment 7

7 years ago
I have to disagree with a WONTFIX so much that I'm reopening the bug and morphing it from localization to standardization.

Look at the screenshot example dates:

1: 11/03/2009
2: 3-11-2009

about:support is for users, presumably ones who need support. These two dates are ambiguous depending on who and where you are. EITHER one could be one of the following:

a: March 11th 2009
b: December 3rd 2009

If a user is just asked "how old" their driver is and they use the date from EITHER source, there is a high potential to to miscommunicate to the one asking the correct information. Yeah, we should probably be going by version, but that's nice and cryptic, and people will use a date for a starting point to see if the problem is because their driver is "old".

If we have a desire for listing any date in about:support for any reason, meaning we expect it to actually be used by the user and whomever is helping them, who may be on the opposite side of the Earth, then we need to make this unambiguous.

Nothing short of YYYY-MM-DD is acceptable for dates in a situation where a date may be transmitted to another person. Hell, in my own locale I have been known to screw up forms with the year at the end.

This is a minor issue that could easily hurt support in a way that may not be noticed.
Status: RESOLVED → REOPENED
OS: Windows 7 → All
Hardware: x86 → All
Resolution: WONTFIX → ---
Summary: Driver date in about:support should be displayed according to locale settings or ISO 8601 → Driver date in about:support should be displayed YYYY-MM-DD (ISO 8601)

Comment 8

7 years ago
(In reply to comment #7)
> b: December 3rd 2009

Er... November.

But the fact that I screwed that up I'm going to somehow use as part of my argument that this should be made as clear as possible. :p

Updated

7 years ago
Blocks: 594464
These dates currently come directly from the registry, so to display them correctly we'd need to parse them and redisplay them. I'd probably be ok with a patch for this.
If the user has Firefox in a language the supporter cannot read, the date becomes unrecognizable for him. So should it look like this?

Driver Date: |toLocaleDateString()| (|toDateString()|)

Comment 11

6 years ago
Can someone confirm that the string in the registry is actually a date in a specific format, and not just some arbitrary string that's in itself ambiguous?
It's the latter.
So should this bug be closed as invalid because it cannot be fixed (except about:support would use a database containing information about the date format of the string...)
We tried that in comment 6.

Jeff says he'd probably take a patch for this bug, so it's not a WONTFIX, but we won't be working on it.
You need to log in before you can comment on or make changes to this bug.