360018 - Date format always en_US (Mac OS X) instead of system setting

Status: VERIFIED FIXED

(Core :: Internationalization, defect)

Description

[Angelo Babudro]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-GB; rv:1.8.1) Gecko/20061010 Firefox/2.0

Similar to bugs 236147 and 315368 (which deal with Linux and Windows), Thunderbird 1.5.0.8 on the Macintosh always displays US-formatted dates (M/D/Y) while the Canadian standard is the same as the UK format (D/M/Y) which is what my system preferences are set to.  I've tried setting my Mac to both Canada and United Kingdom, but the date is always US standard.

A Linux user in one of the above two bug reports said that LC_TIME affected the display (although another disagreed), but EXPORT LC_TIME=en_GB does nothing on the Mac and it appears that OSX doesn't use the LC_ variables (at least not in the same way as Linux).

There is no "user.js" file that I can find (using "find" and "locate"), although in the bug reports mentioned above the person mentioning this file said it didn't work anyway.

I installed two extensions (QuickLocale and ConfigDate) that deal with locale settings in Thunderbird, but neither of them affected the date format (a problem I saw noted in comments to these extensions, but I tried them anyway).

I looked into the Config Editor (under Preferences/Advanced) but that doesn't seem to offer any help.  I searched for "date" and "locale" and got nothing that referenced the date format.


Reproducible: Always

Steps to Reproduce:
1. Set System Preferences date format to Canada or United Kingdom
2. Restart Thunderbird

Actual Results:  
Date is still US format M/D/Y


Expected Results:  
Date should be displayed as D/M/Y

Comment 2

[Maurits]

Similar Bugs
236147 Linux
253883 Windows XP (Not mentioned above.)
315368 Linux
360018 Mac OS X

I see the same error with Thunderbird 2 beta 1 (20061206) On Mac OSX 10.4.8 Intel.

Comment 3

[Björn Victor]

I can confirm the insensitivity to date format settings for Thunderbird version 2.0.0.0 (20070326) on Mac OS X 10.4.9.  Changing the date format in the International system preference does not change the date format in Thunderbird, which still uses US format (D/M/Y h:m AM/PM) in displayed headers and reply text.

I would appreciate very much if this was given some priority; I find the US format very awkward.

Comment 4

[Sava Chankov]

I can confirm this behaviour on Mac OS X 10.4.10 with Thunderbird 2.0.0.6. My international system preferences are set to Bulgarian date format. I also tried running Thunderbird from the Terminal with LC_TIME=bg_BG.UTF-8 /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin

Comment 5

[WADA:World Anti-bad-Duping Agency]

Angelo Babudro(bug opener) and all problem reporters:

(Q1) Does the problem occur even when new profile(and a dummy POP3 account)?
(Q2) What time format is set for LC_TIME in your environment?
 locale -k LC_TIME
 ( http://www.penguin-soft.com/penguin/man?q=locale&section=ALL&action=man )
 ( http://www.penguin-soft.com/penguin/man/1/locale.html )
 ( http://www.penguin-soft.com/penguin/man/5/locale.html )
 ( http://www.penguin-soft.com/penguin/man/7/locale.html )
 ( http://gentoo-wiki.com/HOWTO_localedef )

(In reply to comment #0)
> 1. Set System Preferences date format to Canada or United Kingdom

Where, how, did you do it? 

Comment 6

[Sava Chankov]

(In reply to comment #5)
> (Q1) Does the problem occur even when new profile(and a dummy POP3 account)?

Yes.

> (Q2) What time format is set for LC_TIME in your environment?
>  locale -k LC_TIME

ab_day="Нд ";"Пн ";"Вт ";"Ср ";"Чт ";"Пт ";"Сб "
day="Неделя";"Понеделник";"Вторник";"Сряда";"Четвъртък";"Петък";"Събота"
abmon="Яну";"Фев";"Мар";"Апр";"Май";"Юни";"Юли";"Авг";"Сеп";"Окт";"Нов";"Дек"
mon="Януари";"Февруари";"Март";"Април";"Май";"Юни";"Юли";"Август";"Септември";"Октомври";"Ноември";"Декември"
am_pm="am";"pm"
t_fmt_ampm="%I:%M:%S %p"
era=
era_d_fmt=
era_t_fmt=
era_d_t_fmt=
alt_digits=
d_t_fmt="%a %e %b %X %Y"
d_fmt="%d.%m.%y"
t_fmt="%H:%M:%S"

Comment 7

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #6)
To Sava Chankov:
Is date&time display by Thunderbird inconsistent with your LC_TIME setting? 
See also http://www.penguin-soft.com/penguin/man/3/strftime.html

Comment 8

[Sava Chankov]

(In reply to comment #7)
> (In reply to comment #6)
> To Sava Chankov:
> Is date&time display by Thunderbird inconsistent with your LC_TIME setting? 
Yes.

Comment 9

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #8)
> > Is date&time display by Thunderbird inconsistent with your LC_TIME setting? 
> Yes.
What is the difference(inconsistency) between your LC_TIME settings(such as t_fmt_ampm, d_t_fmt) and date&time display by Thunderbird?  

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #4)
> My international system preferences are set to Bulgarian date format.
Is time format settings in LC_TIME consistent with your system preference settings?

Comment 11

[WADA:World Anti-bad-Duping Agency]

Date&time display by Thunderbird is affected by next preference settings.
(See http://kb.mozillazine.org/Date_display_format)
> mail.ui.display.dateformat.today
> mail.ui.display.dateformat.default
> mail.ui.display.dateformat.thisweek
And, for day of the week display, localized string for day of the week was displayed only when mail.ui.display.dateformat.thisweek was set intentionally (even when set to default value of 4), when I tested above settings with Mozilla in the past(on 2003/11/01).
(See Bug 38990 for display of localized day of the week) 

Will setting change of aboves (or intentional setting to default value) alter Thunderbird behavior on date&time display?

Comment 12

[WADA:World Anti-bad-Duping Agency]

Possibly same as(or similar to) problem of Bug 379279 on Linux which is pointed by the MozillaZine Knowledge Base article.
(http://kb.mozillazine.org/Date_display_format)
> Bug 379279 – LC_LANG environment setting overrides LC_TIME

The article says:
> Note: there is a bug in Thunderbird where LC_ALL overrides the setting of LC_TIME.
> If you have old applications which require LC_ALL to be set to "C",
> then you might find that merely setting LC_TIME is not enough to change the date format.
>
> In order to set this value only for Thunderbird you can either use a separate script
> to invoke thunderbird that contains the following lines:
>
> #!/bin/sh
> export LC_TIME=en_DK  # or whatever you want
> [ "$LC_ALL" != "$LC_TIME" ] && unset LC_ALL # only necessary if set to something different from LC_TIME
> exec <FullPathToYourOriginalThunderbirdCommand>/thunderbird "$@"

Comment 13

[Sava Chankov]

(In reply to comment #9)
> (In reply to comment #8)
> > > Is date&time display by Thunderbird inconsistent with your LC_TIME setting? 
> > Yes.
> What is the difference(inconsistency) between your LC_TIME settings(such as
> t_fmt_ampm, d_t_fmt) and date&time display by Thunderbird?  
d_t_fmt="%a %e %b %X %Y" . Thunderbird behaves as if d_t_fmt="%m/%e/"
%y %l:%M %p"

Comment 14

[Sava Chankov]

(In reply to comment #10)
> (In reply to comment #4)
> > My international system preferences are set to Bulgarian date format.
> Is time format settings in LC_TIME consistent with your system preference
> settings?
Yes.

Comment 15

[Sava Chankov]

(In reply to comment #11)
> Date&time display by Thunderbird is affected by next preference settings.
> (See http://kb.mozillazine.org/Date_display_format)
> > mail.ui.display.dateformat.today
> > mail.ui.display.dateformat.default
> > mail.ui.display.dateformat.thisweek
> And, for day of the week display, localized string for day of the week was
> displayed only when mail.ui.display.dateformat.thisweek was set intentionally
> (even when set to default value of 4), when I tested above settings with
> Mozilla in the past(on 2003/11/01).
> (See Bug 38990 for display of localized day of the week) 
> 
> Will setting change of aboves (or intentional setting to default value) alter
> Thunderbird behavior on date&time display?
No.

Comment 16

[Sava Chankov]

(In reply to comment #12)
> Possibly same as(or similar to) problem of Bug 379279 on Linux which is pointed
> by the MozillaZine Knowledge Base article.
> (http://kb.mozillazine.org/Date_display_format)
> > Bug 379279 – LC_LANG environment setting overrides LC_TIME
No, this is not the case. I have tried what's mentioned in the article. Thunderbird ignores every locale setting on Mac OS X! It behaves as if date format is hardcoded.

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #16)
> No, this is not the case. I have tried what's mentioned in the article.
> Thunderbird ignores every locale setting on Mac OS X! It behaves as if date
> format is hardcoded.

What is set in LC_ALL and LANG?
What about environment setting mentioned in Bug 379279?
Bug 379279 Comment #0 says;
> Steps to Reproduce:
> 1. LANG=C LC_TIME=en_DK.UTF-8 thunderbird  => broken date format
> 2. LANG=  LC_TIME=en_DK.UTF-8 thunderbird  => correct date format
(379279 says also "No problem if LC_ALL is empty/unset, even when case 2".)
(I think workaround in the article is based on this description.          )
(But this may not be applicable to Mac OS X.                              )
 

Comment 18

[Sava Chankov]

(In reply to comment #17)
> (In reply to comment #16)
> > No, this is not the case. I have tried what's mentioned in the article.
> > Thunderbird ignores every locale setting on Mac OS X! It behaves as if date
> > format is hardcoded.
> 
> What is set in LC_ALL and LANG?
> What about environment setting mentioned in Bug 379279?
> (But this may not be applicable to Mac OS X.                              )
Yes, it is not applicable.
LANG= LC_TIME=bg_BG.UTF-8 /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin => broken date format
LANG=bg_BG.UTF-8 LC_TIME=bg_BG.UTF-8 /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin => broken date format
LANG=bg_BG.UTF-8 /Applications/Thunderbird.app/Contents/MacOS/thunderbird-bin => broken date format

System Preferences -> International -> Formats -> Region: Bulgaria (Bulgarian) (! This region can only be used by Unicode applications. WorldScript applications will use the last compatible region).
Dates:
05 януари 2007, петък
05 януари 2007
05.01.2007
05.01.07

Comment 19

[WADA:World Anti-bad-Duping Agency]

Question to rule out operation error.
bash can be chosen when Mac OSX 10.3 or later, but default OSX command shell is tcsh.  
  tcsh : setenv var_name var_values
  bash : export var_name=var_values
  ( http://www.mozilla.org/projects/netlib/http/http-debugging.html )
  ( http://www.cs.hmc.edu/qref/changevar.html                       )
And example in the MozillaZine KB article is written in bash.
Is there no mistake in your manual setting of environment variables?

Comment 20

[Sava Chankov]

(In reply to comment #19)
> Question to rule out operation error.
> bash can be chosen when Mac OSX 10.3 or later, but default OSX command shell is
> tcsh.  
>   tcsh : setenv var_name var_values
>   bash : export var_name=var_values
>   ( http://www.mozilla.org/projects/netlib/http/http-debugging.html )
>   ( http://www.cs.hmc.edu/qref/changevar.html                       )
> And example in the MozillaZine KB article is written in bash.
> Is there no mistake in your manual setting of environment variables?
No, there is no mistake. I'm using bash version 3.2.17(1). LANG-bg_BG.UTF-8 is exported by my user .profile.

Comment 21

[WADA:World Anti-bad-Duping Agency]

Formating of date&time seems to be executed in next modules(FormatTMTime).
>http://lxr.mozilla.org/seamonkey/source/intl/locale/src/windows/nsDateTimeFormatWin.cpp#125
>http://lxr.mozilla.org/seamonkey/source/intl/locale/src/unix/nsDateTimeFormatUnix.cpp#180
>http://lxr.mozilla.org/seamonkey/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp#338
Unix version looks to see LC_TIME contents, but Mac version seems to format to "%y/%m" by strftime always.

> It behaves as if date format is hardcoded.

You seems to be absolutely right...

Comment 22

[WADA:World Anti-bad-Duping Agency]

Adding "Mac OS X" in summary for ease of search, and confirming based on report by four people and detailed test results by Sava Chankov.

Comment 23

[dandaniel]

Hi,

I have been using MAC OS X (10.4.x) up until today and the date format in Thunderbird (version 2.0.0.9 (20071031)) was fine and following my date format settings in the system.

Today after a fresh install to Leopard (Mac OS X 10.5) and Thunderbird version 2.0.0.9 (20071031), I realized that the date format was set to US format (m/d/yy).

After realizing that changing the system settings had no effect on the way Thunderbird is displaying the date format, I followed the instructions given in

http://kb.mozillazine.org/Date_display_format

My findings are as followed (in MAC the user.js is not to be found, instead i used the pref.js):

user_pref("mail.ui.display.dateformat.today", [value]);

For values set to 0, 3 or 4 Thunderbird reacts by displaying date formats setting accordingly. However still not possible to get dd/mm/yy.

But when Value is set to either 1 or 2, no changes would be observed in Thunderbird. Which leads to believe that somehow Thunderbird is unable to read the settings from Leopard.

Comment 24

[dandaniel]

Hi,

After much testing, I come to believe that the Date format always being set to en_us is directly related to Leopard and not to Thunderbird.

I have managed to solve the problem on my install and hope that this would also help all the ones facing the same problem.

To solve the problem I change the REGION setting on the International Format to : UNITED KINGDOM

This solved the case for me immediately. I now understand that if your Region is set to "CUSTOM", applications do not get the system settings correctly and revert by default to en_us.

 

Comment 25

[WADA:World Anti-bad-Duping Agency]

FYI. Bug 368838 looks to be similar issue on Number.toLocaleString().

Comment 26

[Sebastian Winkler]

On the Mac OSX 10.5 side of the issue Firefox is definitely also affected.

Comment 27

[rsx11m]

It is reported in bug 410525 that randomly the 24-hour system time is displayed, or the 12-hour en-US default. This appears to be determined during start-up time and retained for the entire duration of the Thunderbird process. That's different than what is described here, where the set locale is never used for display.

The reporter of that bug was using Mac OS X Tiger.

Comment 28

[Markus Lindström]

I experience the same bug on OS X 10.5.2, but I managed to dig out some more information.

When I got my Mac, it had the US locale selected by default. I changed the region to Belgium in the International system preferences pane, and I now noticed the following warning is shown:

"This region is incompatible with some older applications. Such applications will use the most recent compatible region."

And wouldn't you know, the United Kingdom region does not show this warning! Since the UK formats are fairly close to the ones used in Belgium, I just changed to the UK formats, then changed back to Belgium. As the warning text said, Thunderbird now uses the UK formats since they were "the most recent compatible" ones.

Comment 29

[Sava Chankov]

I can verify that the bug is no longer present when Thunderbird runs on Leopard. I use Bulgarian date format and Thunderbird 2.0.0.9 displays dates correctly on Mac OS X 10.5.3.

Comment 30

[Markus Lindström]

I still experience the same behaviour on OS X 10.5.3, nothing has changed since 10.5.2 ; it seems that as long as one uses an "incompatible" region in the OS X International settings, Thunderbird uses the last "compatible" one.

Comment 31

[rsx11m]

Anything that distinguishes an "incompatible" region from a "compatible" one?

Comment 32

[Markus Lindström]

I have no idea. I would assume there are two ways to access locale settings in an OS X application, an "old" and a "new" one, and only a few locales are accessible through the "old" way (en_US, en_GB and others). OS X seems to store up to two locales at once : the current which may or may not be accessible the "old" way, and the last accessible through the "old" way.

Since Thunderbird apparently uses the "old" way to fetch locale settings (probably the POSIX way ?), OS X delivers the second locale, which leads me to think that changing the way it's handled in the codebase would fix it (i.e. use the OS X API instead).

This is just my own black box speculation of what really happens though.

Comment 33

[s.marshall]

Another data point: I got a new computer and did a fresh install of 10.5, but transferred my Thunderbird profile from the old 10.3 system which exhibited this problem. On this install, Thunderbird now works correctly with UK date settings (24 hour clock). So there does appear to be some OS version dependency. (Note: I gave away the 10.3 computer, so cannot now replicate this problem or test anything. Sorry.)

I am (and was) using UK format which is not on the unsupported list, so while that may be a related issue (i.e. obviously it would be nice if it supported the 'new' way to get date format) it's not the whole of it.

Comment 34

[Wayne Mery (:wsmwk)]

there is also bug 325528 (linux), 

Comment 36

[rsx11m]

> (In reply to comment #34) bug 325528

That's probably a different mechanism. Linux is using the LANG and LC_TIME variables to define the locale, and this seems to work well as long as the respective information is available. Thunderbird examines those on startup.

From forum discussions, users have tried setting those variables as possible workaround, which however didn't change the time/date display on Mac OS X.

Comment 37

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Running a query on mxr shows really rare usage of LC_TIME:
http://mxr.mozilla.org/mozilla-central/search?string=LC_TIME

Magnus, am I correct in saying that this is only implemented on Linux for now? Only nsDateTimeFormatUnix.cpp is listed. Do you know something about?

Comment 38

[Magnus Melin [:mkmelin]]

Looks like mac is using http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/mac/nsDateTimeFormatMac.cpp

Comment 39

[WADA:World Anti-bad-Duping Agency]

Locale is probably obtained by following module.
http://mxr.mozilla.org/mozilla-central/source/intl/locale/src/nsLocaleService.cpp#262

FYI.

"Mac OS X Manual Page For locale(1)" says ;
> http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/locale.1.html
> HISTORY
>  locale appeared in Mac OS X 10.4
This is perhaps the reason why no LANG/LC_TIME use in nsDateTimeFormatMac.cpp.

Following is an Apple's Developers Connection documents relates to Region/Locale.
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/BPInternational.html#//apple_ref/doc/uid/10000171
> Introduction to Internationalization Programming Topics
> http://developer.apple.com/documentation/MacOSX/Conceptual/BPInternational/Articles/ChoosingLocalizations.html#//apple_ref/doc/uid/20002397-SW1
> Getting the Current Language and Locale

Comment 40

[Jonathan Watt [:jwatt]]

Attachment: patch

This bug is due to nsDateTimeFormatMac::FormatTMTime() using the deprecated Carbon function DateString(). Apparently DateString() is not simply deprecated, but is also buggy/incomplete with most locales. The following Apple doc suggests that code using DateString be updated to use CFDateFormatterCreateStringWithDate instead.

http://developer.apple.com/documentation/Carbon/Reference/Date_Time_an_nt_Utilities/DeprecationAppendix/AppendixADeprecatedAPI.html#//apple_ref/doc/uid/TP30000080-CH1g-F08739

Here's a patch that does that. It fixes this bug on my system.

Comment 41

[Simon Montagu :smontagu]

Comment on attachment 356903 [details] [diff] [review]
patch

My mac is away being repaired, and I'd rather wait until it's back before final review, but here are some comments meanwhile:

mCharset, mScriptcode, mLangcode and mRegioncode are all unused with your patch, so you can remove them and the code that initializes them.

>+  if (timeFormatSelector == kTimeFormatSecondsForce24Hour ||
>+      timeFormatSelector == kTimeFormatNoSecondsForce24Hour) 
>+  {

Nit: be consistent with the positioning of {

Comment 42

[Jonathan Watt [:jwatt]]

Simon: good points. I'll try and get back to this, but I'm busy with other things for the next week or so. If anyone else feels like picking the patch up in the mean time, feel free. Just make sure that you assign this bug to yourself so two people don't end up duplicating work.

Comment 43

[Atsushi Sakai]

(In reply to comment #40)
> Created an attachment (id=356903) [details]
> patch

- On my system,

var dts = Components.classes["@mozilla.org/intl/scriptabledateformat;1"]
  .getService(Components.interfaces.nsIScriptableDateFormat);
alert(dts.FormatDateTime("en-US", dts.dateFormatLong,
  dts.timeFormatSeconds, 2008, 6, 30, 12, 56, 34));

generates "June 30, 2008 12:56:34 PM JST".
Is "JST" needed?
kCFDateFormatterMediumStyle may be appropriate rather than kCFDateFormatterLongStyle.

- timeFormatNone is not accepted.

var dts = Components.classes["@mozilla.org/intl/scriptabledateformat;1"]   .getService(Components.interfaces.nsIScriptableDateFormat); alert(dts.FormatDateTime("en-US", dts.dateFormatLong,
  dts.timeFormatNone, 2008, 6, 30, 12, 56, 34));

throws exception.

Comment 44

[Simon Montagu :smontagu]

(In reply to comment #43)

> Is "JST" needed?
> kCFDateFormatterMediumStyle may be appropriate rather than
> kCFDateFormatterLongStyle.

On my system MediumStyle and LongStyle both include the timezone, and I think MediumStyle is too short. Here's the output in a variety of locales:

With kCFDateFormatterLongStyle:
en-US: June 30, 2008 1:56:34 PM PDT 
da-DK: 30. jun 2008 13.56.34 PDT 
en-GB: 30 June 2008 13:56:34 GMT-07:00 
ja-JP: 2008年6月30日 13:56:34:PDT 
ja-JP-mac: 2008年6月30日 13:56:34:PDT 
nn-NO: 30. juni 2008 13.56.34 GMT-07:00 
nb-NO: 30. juni 2008 13.56.34 GMT-07:00
no-NO: 30. juni 2008 13.56.34 GMT-07:00
sv-SE: måndag 30 jun 2008 13.56.34 PDT 
he-IL: 13:56:34 GMT-07:00 30 יוני 2008 
kok: 2008 जून 30 13:56:34 GMT-07:00 
gu-IN: ૩૦ જૂન ૨૦૦૮ ૦૧:૫૬:૩૪ ઉત્તર મધ્યાહ્ન GMT-૦૭:૦૦ 
ab-CD: June 30, 2008 1:56:34 PM PDT 

With kCFDateFormatterMediumStyle:
en-US: Jun 30, 2008 1:56:34 PM PDT 
da: 30/06/2008 13.56.34 PDT 
da-DK: 30/06/2008 13.56.34 PDT 
en-GB: 30 Jun 2008 13:56:34 GMT-07:00 
ja-JP: 2008/06/30 13:56:34:PDT
ja-JP-mac: 2008/06/30 13:56:34:PDT 
nn-NO: 30. jun. 2008 13.56.34 GMT-07:00 
nb-NO: 30. jun. 2008 13.56.34 GMT-07:00 
no-NO: 30. jun. 2008 13.56.34 GMT-07:00 
sv-SE: 30 jun 2008 13.56.34 PDT 
he-IL: 13:56:34 GMT-07:00 30/06/2008 
kok: 2008 जून 30 13:56:34 GMT-07:00 
gu-IN: ૩૦-૦૬-૨૦૦૮ ૦૧:૫૬:૩૪ ઉત્તર મધ્યાહ્ન GMT-૦૭:૦૦ 
ab-CD: Jun 30, 2008 1:56:34 PM PDT 

We can always fix up the format string to remove the time zone, similarly to what the current patch does for the force-24-hour options.

Comment 45

[Atsushi Sakai]

Attachment: patch using MediumStyle for time format

(In reply to comment #44)
> On my system MediumStyle and LongStyle both include the timezone, and I think
> MediumStyle is too short. Here's the output in a variety of locales:

It seems like MediumStyle is used for date format,
but I meant for time format.

Here's the output on my Mac OS X 10.5.6:
en-US: June 30, 2008 1:56:34 PM
da: 30. jun 2008 13.56.34
da-DK: 30. jun 2008 13.56.34
en-GB: 30 June 2008 13:56:34
ja-JP: 2008年6月30日 13:56:34
ja-JP-mac: 2008年6月30日 13:56:34
nn-NO: 30. juni 2008 13.56.34
nb-NO: 30. juni 2008 13.56.34
no-NO: 30. juni 2008 13.56.34
sv-SE: må 30 jun 2008 13.56.34
he-IL: 13:56:34 30 יוני 2008
kok: 2008 जून 30 13:56:34
gu-IN: ૩૦ જૂન ૨૦૦૮ ૦૧:૫૬:૩૪ ઉત્તર મધ્યાહ્ન
ab-CD: 2008年6月30日 13:56:34


> We can always fix up the format string to remove the time zone, similarly to
> what the current patch does for the force-24-hour options.

It seems difficult because delimiter is different between locales.
E.g. " "(space) is used for many locales but ":" is used for ja-JP.

Comment 46

[Simon Montagu :smontagu]

(In reply to comment #45)
> It seems like MediumStyle is used for date format,
> but I meant for time format.

Sorry, it was stupid of me not to realize that (if possible I'll try to claim that the name of the constant "kCFDateFormatterMediumStyle" confused me, and shift some of the blame on to Apple).

I have an almost finished version of Johnathan's patch which addresses my comments in comment 41, and also the bug with timeFormatNone (and with dateFormatNone) that you mentioned earlier. I'll add the change to MediumStyle for the time format.

Comment 47

[Simon Montagu :smontagu]

Attachment: Patch with all suggested changes

This is basically Jonathan's patch from attachment 356903 [details] [diff] [review], with my own review comments from comment 41; some more unused code removed; using kcfDateFormatterMediumStyle for time; added code to handle dateFormatNone and timeFormatNone; and last but not least using localtime_r instead of localtime because with localtime the buffer can get overwritted before it's used.

Comment 48

[John Daggett (:jtd)]

Comment on attachment 367488 [details] [diff] [review]
Patch with all suggested changes

Looks fine, although I can see situations where CFLocaleCopyCurrent is different from the localization of FF (e.g. en-US running with default user locale set to Japanese).  Not a huge deal but maybe something to comment on?

Comment 49

[Simon Montagu :smontagu]

(In reply to comment #48)
> I can see situations where CFLocaleCopyCurrent is
> different from the localization of FF (e.g. en-US running with default user
> locale set to Japanese).  Not a huge deal but maybe something to comment on?

That is the status quo, which this isn't intended to change. Bug 441167 was intended to change it, but it was backed out; partly because of regressions on Mac which this patch and the Mac patch in bug 22310 will prevent, and partly because of other considerations -- see comments in bug 441167 and bug 419220.

Comment 50

[Simon Montagu :smontagu]

http://hg.mozilla.org/mozilla-central/rev/d5d803d36ee5

Comment 51

[Jonathan Watt [:jwatt]]

Thanks for finishing this and getting it reviewed and pushed Simon!

Comment 52

[Marco Bonardo [:mak]]

this set yearMonth to yy/MM, but if i'm not wrong old version and other platforms make yyyy/MM.

Comment 53

[Atsushi Sakai]

(In reply to comment #52)
> other
> platforms make yyyy/MM.

On Windows, dateFormatYearMonth's result is yyyy/MM.
On Linux, dateFormatYearMonth's result is yy/MM.
It would be better if it's consistent, but it has never been so.

Comment 54

[Marco Bonardo [:mak]]

(In reply to comment #53)
> (In reply to comment #52)
> > other
> > platforms make yyyy/MM.
> 
> On Windows, dateFormatYearMonth's result is yyyy/MM.
> On Linux, dateFormatYearMonth's result is yy/MM.

any reason for that? i think most common and ISO date formats have the 4 digits year. So is it wanted on Mac and Linux having yy/MM?

Comment 55

[Atsushi Sakai]

(In reply to comment #54)
> > On Windows, dateFormatYearMonth's result is yyyy/MM.
> > On Linux, dateFormatYearMonth's result is yy/MM.
> 
> any reason for that? i think most common and ISO date formats have the 4 digits
> year. So is it wanted on Mac and Linux having yy/MM?

Filed Bug 483769 for that.

Comment 56

[Simon Montagu :smontagu]

Covered by the test for bug 22310

Comment 57

[Simon Montagu :smontagu]

Attachment: Patch for branch

Requesting branch approval after baking time. This is worth taking on branch because it fixes display of dates in many places in the UI in locales other than en-US -- e.g. bug 482549. The patch includes Atsushi's patch for bug 483769.

Comment 58

[(not currently active) Ted Mielczarek]

Comment on attachment 368696 [details] [diff] [review]
Patch for branch

a191=drivers conditional on landing the tests from bug 22310 on branch as well.

Comment 59

[Simon Montagu :smontagu]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/c0fb52b14fd8 (including the tests from bug 22310, plus the change to them in bug 485278)

Comment 60

[Simon Montagu :smontagu]

... the change to them in bug 485728

Comment 61

[Yuxuan Wang]

I think this is not fixed yet. I downloaded latest-comm-central build (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090415 Lightning/1.0pre Shredder/3.0b3pre) and it still didn't respect the Format setting in my System Preferences -> International. I guess it's because my LANG is set to en_US?

$ env | grep en_US
LANG=en_US.UTF-8

Comment 62

[Mark Banner (:standard8)]

(In reply to comment #61)
> I think this is not fixed yet. I downloaded latest-comm-central build
> (Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre)
> Gecko/20090415 Lightning/1.0pre Shredder/3.0b3pre)

The fix has only just been checked in to the 3.0x (gecko 1.9.1) builds. It should be in Gecko/20090416 (out in a few hours) but may be worth waiting until Gecko/20090417 just to be sure.

Comment 63

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Verified fixed on trunk and 1.9.1 with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090421 Minefield/3.6a1pre ID:20090421032809

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090421 Shiretoko/3.5b4pre ID:20090421030848

Comment 64

[Wayne Mery (:wsmwk)]

to what extent does this affect 
 Bug 105045 -  update date/time formatter on Mac OS X (CFDateFormatter)
 Bug 511052 -  date toLocaleString actually ignores locale and always showes US format