544315 - When the birth year is empty, thunderbird put 1900 and in english language

Status: RESOLVED FIXED

(Thunderbird :: Address Book, defect)

Description

[Möbius]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.2) Gecko/20100115 Firefox/3.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; es-AR; rv:1.9.1.7) Gecko/20100111 Lightning/1.0b1 Thunderbird/3.0.1

When the year of born is empty, thunderbird put 1900 and in english language, my TB is in spanish. Also, it should show as "born date", not birth date.
Example: I borned on monday, but my  birth date day is (this year) on sunday

Reproducible: Always

Steps to Reproduce:
1.Put in the date of birthdate
2.Leave empty the year (or age)
3. OK
Actual Results:  
thunderbird put 1900 and in english language (the day name)
Also, it should show as "born date", not birth date

Expected Results:  
Leave in blank the year, display only day and month, and in the language of thunderbird.

Comment 1

[[:Aureliano Buendía]]

WFM

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100204 Lightning/1.1a1pre Lanikai/3.1b1pre ID:20100204032612

Pablo could try if this happeans also in safe-mode? See how to start TB in safe-mode here http://kb.mozillazine.org/Safe_mode

Comment 2

[Möbius]

Yes, the same

Comment 3

[石庭豐 (Seak, Teng-Fong)]

I can confirm this as well.

However, for "Expected results", I would not expect "the language of Thunderbird".  Instead, I would expect it in the language/format specified in the underlying O/S.

For example, my Windows and TB are all in English.  But my regional settings is set to French.  So I would expect the date-string to be written in French.

Or maybe TB should provides an option to choose if the underlying O/S setting is used or not.  But this change seems more like a RFE and is not suitable for this bug.

PS: I'm not quite sure to understand the subtlety between birth-date and born-date.

Comment 4

[Möbius]

> PS: I'm not quite sure to understand the subtlety between birth-date and
> born-date.

Maybe is subtlety in english language (my bad english language):
In spanish TB say "Cumpleaños" 
and should show "fecha de nacimiento" or "nació..."
Translating: 
Cumpleaños: Date when I will make the next party (FUTURE). The TB date is in the past.
Fecha de nacimiento = Nació: date of birth (PAST)

I do understand? I specified? Sorry my bad english

Comment 5

[石庭豐 (Seak, Teng-Fong)]

Oh, I see.  Your birth-year/born-year issue is actually a localization (l10n) issue.  In other words, it's related to user interface language.  You should file another bug for it, because this bug is independent of any particular interface language.

Comment 6

[Möbius]

I understand.
Thanks

Comment 8

[Andre Klapper]

Also see bug 705273

Comment 9

[石庭豐 (Seak, Teng-Fong)]

Could we change "year of born" in the title to "birth-year"?

Comment 10

[Samuel Müller]

Attachment: a script to test the behaviour of toLocaleFormat()

The problem lies in the non-standard toLocaleFormat() function (see https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Date/toLocaleFormat). I guess it is a problem of Gecko in general, because it is also repeatable in Firebug.

toLocaleFormat() returns an English GMT string for some formats. The function appears to return a GMT string as soon as an unsupported format it passed as a part of the parameter.

The en-US locale uses "%B %e" to format the date. "%e" does not seem to work, while "%B" works fine and displays the full month.

Comment 11

[Samuel Müller]

toLocaleFormat() seems to be buggy on Windows: bug 459844, bug 528520
... also on OSX: bug 476419

Mark Banner suggested to use nsIScriptableDateFormat instead (https://bugzilla.mozilla.org/show_bug.cgi?id=476419#c5), though there is no documentation on it.

Comment 12

[Samuel Müller]

Attachment: a workaround

I came up with a workaround while still allowing to use "%e" for the day of the month.
If the proposal is accepted, I'll create a patch.

Comment 13

[Samuel Müller]

Attachment: a script to test the behaviour of toLocaleFormat()

month was not zero-indexed

Comment 14

[Samuel Müller]

Attachment: a workaround

month was not zero-indexed

Comment 16

[Samuel Müller]

Attachment: using workaround

this patch fixes the issue using the approach from above, however I think it is bad to use the system language to format the date. It should use the UI language, everything else just look weird. In my case (tb 11.0a1) there is an English-formatted date with a German month name appearing in an English TB on a German OS.
It does not matter that the formatting of the date is different from the OS, because the user willingly installed a software using not the language of the OS.

Comment 17

[石庭豐 (Seak, Teng-Fong)]

(In reply to Samuel Müller from comment #16)
> 
> this patch fixes the issue using the approach from above, however I think it
> is bad to use the system language to format the date. It should use the UI
> language, [snipped...]

This viewpoint is arguable.  My O/S is English, just like my TB is also English; but system locale is set to French.

I chose English because it's easier to know where in the GUI and what components I should click/choose if I'm following some kind of procedure (and I don't want to do all the translations all the time -- which sometimes is just impossible because of bad translation in localized UI)

I mean, if a user wants to make system locale *different* from system/application GUI language, there's a real reason behind and this should be respected in the first place.

Comment 18

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 580040 [details] [diff] [review]
using workaround

Hm.

I think I'm of the mind that Thunderbird should respect the OS's date/time formats.  It's Thunderbird's responsibility to integrate nicely into the operating system, and if we go "rogue" on this, it means injecting a possible point of inconsistency that might confuse our users.

And I realize that we could *still* have inconsistency between Thunderbird's locale and the date format, but I'm pretty sure system consistency trumps locale consistency in this case.

That's my position on it, anyhow.

Comment 19

[Samuel Müller]

(In reply to Mike Conley (:mconley) from comment #18)
> Comment on attachment 580040 [details] [diff] [review]
> using workaround
> 
> Hm.
> 
> I think I'm of the mind that Thunderbird should respect the OS's date/time
> formats.  It's Thunderbird's responsibility to integrate nicely into the
> operating system, and if we go "rogue" on this, it means injecting a
> possible point of inconsistency that might confuse our users.
> 
> And I realize that we could *still* have inconsistency between Thunderbird's
> locale and the date format, but I'm pretty sure system consistency trumps
> locale consistency in this case.
> 
> That's my position on it, anyhow.

I see your point, but what's your solution to the problem that the address book specifically allows to enter birthdays without specifying the year? 
There is no OS date format without a year and the current locale-dependent implementation fails on windows systems (displaying an English formatted GMT date/time string regardless of the OS language/settings).

Comment 20

[Jim Porter (:squib)]

Attachment: Fix this

This is totally untested, but based on bug 459844, this should fix the issue, and has the happy benefit of not being a workaround. Do we want to change the string name here?

Comment 21

[Ian Neal]

(In reply to Jim Porter (:squib) from comment #20)
> Created attachment 817534 [details] [diff] [review]
> Fix this
> 
> This is totally untested, but based on bug 459844, this should fix the
> issue, and has the happy benefit of not being a workaround. Do we want to
> change the string name here?

I would say ideally yes, so that localisers catch it, a possible alternative is to post into the relevant l10n forums but some localisers might not see that.

Comment 22

[石庭豐 (Seak, Teng-Fong)]

Does attachment 817534 [details] [diff] [review] mean that dateformat would follow Thunderbird's localized order instead of O/S regional settings?  I mean, suppose TB is in US English but O/S regional setting is set to Spanish (for which date format is Day Month Year)

The result string is still "Month Day" instead of "Day Month", right?

An ideal solution is to use date.toLocaleDateString()
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString

where we would specify "options" argument whose "formatMatcher" attribute would contain "month, day"

Unfortunately, the arguments for this method are not implemented in Gecko yet.  And no idea if its support is planned in a near future or not.

Comment 23

[Jim Porter (:squib)]

(In reply to 石庭豐 (Seak, Teng-Fong) from comment #22)
> Does attachment 817534 [details] [diff] [review] mean that dateformat would
> follow Thunderbird's localized order instead of O/S regional settings?  I
> mean, suppose TB is in US English but O/S regional setting is set to Spanish
> (for which date format is Day Month Year)
> 
> The result string is still "Month Day" instead of "Day Month", right?

Yeah, that's what will happen, but it's what happens now too, so this patch doesn't make things any worse.

Comment 24

[Jim Porter (:squib)]

Attachment: Updated patch with string name changed

Ok, I changed the string name. I think we should take this patch, since it improves things for Windows users (the majority of our user population), and doesn't make things any worse for localization.

It'd be nice to have a proper solution for this that uses the system locale, but we can always do that in the future when we have a better API that allows us to do that.

It'd be *really* nice if we could get this for TB24, but that wouldn't be too nice for localizers, so I suppose we can wait.

Comment 25

[石庭豐 (Seak, Teng-Fong)]

(In reply to Jim Porter (:squib) from comment #23)
> Yeah, that's what will happen, but it's what happens now too, so this patch
> doesn't make things any worse.

Please don't get me wrong.  I'm very happy that we're finally getting rid of this "1900" confusing bug in Windows :)  I just wanted to know to what degree this bug would be fixed.

Actually, %B will show the localized month string from O/S regional settings and this is the recommended way to do.  It's just the month-day order relying on TB language which might be inconvenient for special cases.  We'll see later if this order matters to users in special cases -- anyway, they could open another bug if wanted.

About the patch, I don't understand why line 299 of abCardViewOverlay.js is changed to
// if the year doesn't exist, display Month DD (ex. January 1)

This change of comment is misleading because %d means *zero-leading* number.  Please add back the zero in front of "1".

Please also take advantage of this bug fixed opportunity to create a function, eg getFormattedBirthdayString, to make the whole block from line 287 to line 304 cleaner. Or you could make a method for card object if you like.

In addressBook.properties, please add comment to warn localizers that %Oe and %Od are not supported in Windows.

Comment 26

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 819304 [details] [diff] [review]
Updated patch with string name changed

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

This works for me. Thanks Jim! And sorry for the wait.

Comment 27

[Jim Porter (:squib)]

Landed: https://hg.mozilla.org/comm-central/rev/88420197ae6b