Open Bug 456220 Opened 16 years ago Updated 2 years ago

Birthday and month shown in card view aren't localized well

Categories

(MailNews Core :: Address Book, defect)

defect

Tracking

(Not tracked)

ASSIGNED

People

(Reporter: pi, Assigned: pi)

References

Details

Attachments

(1 file, 1 obsolete file)

Attached patch Work in progress (obsolete) — Splinter Review
The reporter of bug 455797 mentioned the date being displayed as:
Sat Jan 20 1900 00:00:00 GMT +0100
when only a date and month were entered in the birthday field.  I do not know why date.toLocaleFormat does that, but there are other problems with doing it this way.

Right now the format only changes based on the locale, and all en-US builds will show MonthName day (September 21) if only the month and date are provided, but the system's short date format (09/20/2008 for me) if the year is provided.

This attachment is a work in progress, but should work.  It essentially removes the year from the system's short date format.  It includes changes also in the patch for bug 455797.
Attached patch PatchSplinter Review
This is the patch for review since the patch for bug 455797 was checked in.
Attachment #339603 - Attachment is obsolete: true
Attachment #339669 - Flags: review?(bugzilla)
Shouldn't we investigate fixing the core date.toLocaleFormat() issue? CCing some people based on cvs blame for http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/js/src/jsdate.c&rev=3.111&mark=1850#1850

From bug 455797 comment 6:
> alert(new Date().toLocaleFormat("%B %e"));
Thu Sep 18 2008 22:40:05 GMT +0200
(using an en-US nightly on a German Windows)
Flags: blocking-thunderbird3?
Steffen, I'd be interested to know what the result of calling strftime from a c/c++ executable with the "%B %e" format (which is what toLocaleFormat ends up calling) - that is if you are able to.

It seems to be behaving fine on mac.

Generally I think I prefer the month as a word and then the day as a number.
It crashes. Because "%e" doesn't seem to be supported on Windows:
http://msdn.microsoft.com/en-us/library/fe06s4ak%28VS.80%29.aspx

"%B %d" results in "Oktober 09".
So does alert(new Date().toLocaleFormat("%B %d"));

> Generally I think I prefer the month as a word and then the day as a number.
Me too, but the other way round and with a dot after the day: "31. Dezember" is the convention in Germany...
Comment on attachment 339669 [details] [diff] [review]
Patch

I definitely think we want a text month and somehow appropriate detection for the system's current settings.
Attachment #339669 - Flags: review?(bugzilla) → review-
Depends on: 459844
So as a workaround, I'd change "%B %e" to "%B %d" here:
http://hg.mozilla.org/comm-central/annotate/ae92cd7377a7/mail/locales/en-US/chrome/messenger/addressbook/addressBook.properties#l96.
Instead of "October 3", we'd have "October 03".
I could easily just detect the order of the month/day for the system (already done in the previous patch) and use toLocaleFormat("%B") to get the localized month and put the number before or after that string.  No %e or %d needed, so hopefully %B works.

Steffen Wilberg, would you please try this and let me know what it shows (should be the current month):
alert(new Date().toLocaleFormat("%B"));

If we change this to show the month name and day, should we also change what is displayed when the year is present (Currently MM/DD/YYYY or DD/MM/YYYY)? (October 18 would become 10/18/2008 after adding 2008 as the year)

If so, (new Date()).toDateString(); returns "Sat Oct 18 2008" , which is fine for me, but I'm not sure if the day/month order changes.
The nicest solution would be to make "%e" work on Windows in general (bug 459844).

If that doesn't happen, I'd use "%B %d" and strip the initial zero from the day, i.e. a zero followed by a number. Localizers can then use the appropriate format in addressBook.properties, e.g. "%d %B" or "%d.%B" or whatever.

alert(new Date().toLocaleFormat("%B")); results in "Oktober", i.e. the localized full month.

Regarding the full date, I already see "Sonntag, 19. Oktober 2008" here, which is fine.
(In reply to comment #8)
> The nicest solution would be to make "%e" work on Windows in general (bug
> 459844).
> 
> If that doesn't happen, I'd use "%B %d" and strip the initial zero from the
> day, i.e. a zero followed by a number. Localizers can then use the appropriate
> format in addressBook.properties, e.g. "%d %B" or "%d.%B" or whatever.
> 
> alert(new Date().toLocaleFormat("%B")); results in "Oktober", i.e. the
> localized full month.
Good, thanks.  I guess the two options are to detect the order of the day and month, then display the localized month name and day in the detected order or to use %B and %d and have the localizers choose the order and any separator.  If Germany uses a period I think your suggestion is best.

> Regarding the full date, I already see "Sonntag, 19. Oktober 2008" here, which
> is fine.
Ok, I get a similar result in Windows (Sunday, October 19, 2008) and 10/19/2008 in Linux en-US.
(In reply to comment #9)
> Good, thanks.  I guess the two options are to detect the order of the day and
> month, then display the localized month name and day in the detected order or
> to use %B and %d and have the localizers choose the order and any separator. 
> If Germany uses a period I think your suggestion is best.

I'm still not sure localised items are the right way to go here - the user can set up their system how they want, if I use en-GB and set my system up so that it uses German style dates, it should respect the system preference.
Not blocking, although some resolution would be nice.
Flags: wanted-thunderbird3+
Flags: blocking-thunderbird3?
Flags: blocking-thunderbird3-
My latest patch (1.3) for Bug 456024 should improve the card view pane.  The displayed date in the card view pane should match what the new datepicker displays because they use the same JS module to detect the short date format.

My short date format is MM/DD/YYYY and I get either
07/06 or 07/06/2009 in Windows and Linux.  Should I remove the card view portion of the patch in 456024 and attach it here after it lands?
I'm tempted to mark this as a duplicate of Bug 456024 since the current patch detects the system's current short date format and does not need to be localized.  The birthday in the card view should match the datepicker plus the year, if any was given.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: