Closed Bug 1567820 Opened 6 months ago Closed 6 months ago

Console erorr: initLocaleShortDateFormat: could not analyze the date format, defaulting to mm/dd/yyyy - dateFormat.js:41

Categories

(MailNews Core :: General, defect)

defect
Not set

Tracking

(thunderbird_esr68 fixed, thunderbird69 fixed, thunderbird70 fixed)

VERIFIED FIXED
Thunderbird 70.0
Tracking Status
thunderbird_esr68 --- fixed
thunderbird69 --- fixed
thunderbird70 --- fixed

People

(Reporter: jorgk-bmo, Assigned: jorgk-bmo)

Details

Attachments

(2 files, 3 obsolete files)

Comes from this code:

    const dateFormatter = new Services.intl.DateTimeFormat(undefined,
      { dateStyle: "short" });
    var aDate = new Date(1999, 11, 1);
    var dateString = dateFormatter.format(aDate).replace(/ /g, "");

I have my short date format set to "dd MMM yyyy", so this returns "01 Dec 1999".

After removing spaces, the string can no longer be split and we report this error further down at line 41:
https://searchfox.org/comm-central/rev/e1cad4fa7802792790e7a5a2d64aad51241a2bec/mailnews/base/content/dateFormat.js#41

The error comes up when launching the "search messages" panel.

This should do it.

Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Attachment #9079666 - Flags: review?(geoff)

We might as well dump out the unrecognised format.

Attachment #9079666 - Attachment is obsolete: true
Attachment #9079666 - Flags: review?(geoff)
Attachment #9079667 - Flags: review?(geoff)

Actually, let's get rid of the horrible confusing constants 1-6 while we're here.

Attachment #9079667 - Attachment is obsolete: true
Attachment #9079667 - Flags: review?(geoff)
Attachment #9079677 - Flags: review?(geoff)

Coming to think of it, the hand-rolled parsing and formatting dates is pretty rubbish, especially since locales don't set those prefs:
https://dxr.mozilla.org/l10n-central/search?q=search_date_format&redirect=false
https://dxr.mozilla.org/l10n-central/search?q=search_date_separator&redirect=false

This preference should go and all the rubbish that goes with it and we should instead just format the dates properly.

OK, I tried what I said in comment #4. With that I got "22 Jul 2019" in the search box. Sadly it's hard to parse into a time value, since we'd have to detect the alpha month of "Jul".

So let's go with the other patch. We could still rip the preferences out since the are a no-op. Any opinion, Geoff?

Comment on attachment 9079677 [details] [diff] [review]
1567820-initLocaleShortDateFormat.patch (v3)

Review of attachment 9079677 [details] [diff] [review]:
-----------------------------------------------------------------

::: mailnews/base/content/dateFormat.js
@@ +90,5 @@
>        initLocaleShortDateFormat();
>      } else {
>        // initialize the search date format based on preferences
> +      if (gSearchDateFormat < formatMIN || gSearchDateFormat > formatMAX)
> +        gSearchDateFormat = formatMDY;

Should be switch this it the more international
YMD? MDY is pretty US-centric.

@@ +108,5 @@
>    }
>  
>    if (gSearchDateFormat == 0) {
>      // Set to mm/dd/yyyy in case we couldn't determine in any way.
> +    gSearchDateFormat = formatMDY;

And here.
Comment on attachment 9079677 [details] [diff] [review]
1567820-initLocaleShortDateFormat.patch (v3)

Yes, I think the default should be YMD, it's the least likely to cause confusion.

In the bigger picture, we should offer the user a date picker in the places where this code is used. AFAICT the only consumers are the search messages dialog, and the mark as read by date dialog. If we used a fixed-format picker (e.g. the full HTML <input> picker which doesn't currently work) we could remove this file altogether.
Attachment #9079677 - Flags: review?(geoff) → review+
Attachment #9079920 - Flags: approval-comm-esr68+
Attachment #9079920 - Flags: approval-comm-beta+

Pushed by mozilla@jorgk.com:
https://hg.mozilla.org/comm-central/rev/f3489a1ec9f4
Fix cheap short date parsing in initLocaleShortDateFormat(). r=darktrojan

Status: ASSIGNED → RESOLVED
Closed: 6 months ago
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 70.0

Working in TB 69 beta.

Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.