Open Bug 1538182 Opened 6 years ago Updated 6 months ago

All-numeric date format is ambiguous in reply header

Categories

(Thunderbird :: Message Compose Window, enhancement)

Product:
Thunderbird
Component:
Message Compose Window
Type:
enhancement

Tracking

(Not tracked)

People

(Reporter: varnavruz, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Steps to reproduce:

Reply to any mail with locale set to English (United States), header will read:

On 8/3/2019 05:06, Alice wrote:

Reply to any mail with locale set to English (United Kingdom) or tens of other locales, header will read:

On 03/08/2019 05:06, Alice wrote:

Actual results:

This is a non issue as long as emails do not cross country borders, that is uncommon today. We're working with different nations with different date formats, and it's ok that every nation uses it's own. But in this specific case date like 8/3/2019 will be interpreted as 3rd day of August by someone from US, and as 8th day of March by almost everyone from outside US.

Expected results:

Reply header must use long date format. For US locale:

On August 3, 2019 05:06, Alice wrote:

And for UK locale:

On 3 August 2019 05:06, Alice wrote:

This will eliminate ambiguity still honoring local standards.

Yes, on Windows we use the short date for this purpose, you're saying we should use the long date instead.

You can configure Windows' short date format.
Ugly workaround would be to select yyyy-MM-dd as the short date format or configure your short date format to be dd MMMM yyyy. That's also possible.

yyyy-MM-dd gives: On 2019-03-24 00:57, Bugzilla@Mozilla wrote:,
dd MMMM yyyy gives: On 24 March 2019 00:57, Bugzilla@Mozilla wrote:
dd MMM yyyy gives: On 24 Mar 2019 00:57, Bugzilla@Mozilla wrote:

That will affect all Windows applications, so dd MMM yyyy is the least annoying.

Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Component: Untriaged → Message Compose Window
Ever confirmed: true

Thunderbird should use the ISO 8601 format (2021-07-31 or 2021-07-31T19:06:25+00:00) instead, or at least provide an option for it. The current format is not only ambiguous between mm/dd/yyyy and dd/mm/yyyy but also doesn't indicate the time zone.

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.