User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081021 SeaMonkey/2.0a2pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2pre) Gecko/20081021 Calendar/1.0pre My setting for time display under Windows XP is 18:51:26. Starting with trunk migration to hg 1.0pre time in Sundbid is displayed as PM 6:51. With Sunbird 0.6 (trunk) the problem did not occur. Reproducible: Always

I just realized that time is displayed as PM/AM in the calendar view only. In the event dialog the time is still displayed as 18:51. But therefor I noticed that the date in the event dialog is displayed in US style (11/9/2008) and not in German style 11.09.2008 as set in the OS.

See Bug 399605 that requests the complete opposite. For a long time Sunbird/Lightning tried to use the OS date/time format wherever possible. Except a few places this worked very well. Unfortunately the view overhaul in 0.9 regressed this very much by using localization specific date/time formats again. Now we have a mixup of date/times in OS format and date/times in localization specific format. Calendar drivers should decide which way to go for Sunbird/Lightning.

Drivers decided to head towards a consistent application. If the app has been localized, it looks odd to mix in a different style for date/time. It should look consistent for the same (app==system) locale though. So what's the bug after all? (In reply to comment #1) > I just realized that time is displayed as PM/AM in the calendar view only. In IMO OK since it's en-US. > the event dialog the time is still displayed as 18:51. I think the time picker is always xx:yy regardless of the locale. IMO not necessarily a bug, because it's commonly used in en-US, too. > But therefor I noticed that the date in the event dialog is displayed in US > style (11/9/2008) and not in German style 11.09.2008 as set in the OS. IMO OK since it's en-US.

(In reply to comment #3) > Drivers decided to head towards a consistent application. If the app has been > localized, it looks odd to mix in a different style for date/time. It should > look consistent for the same (app==system) locale though. > So what's the bug after all? In case the localization should overrule the system settings there is no bug. Coming from 0.9 there seemed to be a bug as with 0.9 system settings where used. From this new point of view for me I will resolve this bug a invalid.

(In reply to comment #3) > If the app has been > localized, it looks odd to mix in a different style for date/time. > So what's the bug after all? I think the "bug" is that the OS offers better customization of dates/times than Lightning does. In the U.S. for example I set 24-hour time in my OS. If Lightning is going to ignore the OS then I think it should at least let us choose between 14:00 and 2:00 PM. IMO people in the U.S. should not be forced to use AM/PM because it wastes three precious characters in month view that could be used to show more of the event titles. This is probably bug 271162 ("Ability to configure event time display formatting in event box").

Reopening, I find this *totally* unacceptable! Thunderbird uses OS time/date all over the place, and we're a lot of people using en-US builds but certainly not en-US time format. For instance AM/PM formats always make me think twice. It's not what my system is set to and it's not what I want.

According to bug 468865 comment 0, this affects Windows, but not Linux. I consider this a blocker as well.

I'd say this is a blocker (blocking-calendar1.0+), but I doubt its a requirement for Lightning to be integrated into Thunderbird (tb-integration-).

(In reply to comment #7) > Thunderbird uses OS time/date all over the place, and we're a lot of people > using en-US builds but certainly not en-US time format. I don't consider this a strong argument. Even Thunderbird mail looks strange, e.g. showing "Date 17:39 Uhr" on my english Mac OSX with german date format. > For instance AM/PM formats always make me think twice. It's not what my system > is set to and it's not what I want. True. I don't like that, too, and it looks inconsistent to the rest of the application. If I see this correctly, it affects the today pane and the event tooltips. I yet don't see where we use l10n specific time formats. Berend, could you please enlighten me?

(In reply to comment #10) > Even Thunderbird mail looks strange, > e.g. showing "Date 17:39 Uhr" on my english Mac OSX with german date format. It's not strange on Windows, where it just shows the time in 24H format, without "Uhr". > > For instance AM/PM formats always make me think twice. It's not what my system > > is set to and it's not what I want. > True. I don't like that, too, and it looks inconsistent to the rest of the > application. If I see this correctly, it affects the today pane and the event > tooltips. - In the day and week views, the calendar-time-bar to the left, - In the multiweek and month views, the calendar-month-day-box-item-label (except for all-day events, which don't show the time), - In the Find Events box, - Options -> Lightning -> Views -> Day starts at / day ends at, - Tasks Start Date / Due Date / Status (completed date). - The New Event/Edit Event has this bug the other way round, since it's 24H everywhere (bug 255668).

Sunbird/Lightning uses nsIScriptableDateFormat from the Mozilla Toolkit to get a date/time format according to the specified locale. Because no locale is specified the default locale is used. On the 1.8.1 branch nsIScriptableDateFormat defaults to the OS locale. On the 1.9.1 branch nsIScriptableDateFormat defaults to the application locale. This behavior was changed with Bug 441167 in Toolkit on purpose. I can verify that it works this way. If I run a Sunbird win32 1.0pre en-US build I get a time like "9:15 PM". If I run a Sunbird win32 1.0pre de-DE build I get a time like "21:15".

Ah, bug 441167 that explains it. The reason it's working fine for me on linux is I don't have the "en-US" locale set up and thus I get the fallback locale which is the OS locale. (I do have "en-US.utf8" set up though.) I can understand how you'd like for dates not to be displayed like "22. juni 2008 20:06" in an en-US calendar - I agree that's not so nice for full sentence dates. (Not sure if dates are displayed like that anywhere though.) When you're displaying only numeric dates, or hours only it definitely not what you want.

(In reply to comment #13) > I can understand how you'd like for dates not to be displayed like "22. juni > 2008 20:06" in an en-US calendar - I agree that's not so nice for full sentence > dates. (Not sure if dates are displayed like that anywhere though.) > > When you're displaying only numeric dates, or hours only it definitely not what > you want. I don't think there is a difference in numeric vs non numeric. When an application with a user interface written in American English displays a date like "1/2/2008", I will read that as the second of January no matter what my OS locale is. If it meant first of February, I would consider that a bug. However I do consider 12H/24H somewhat of a personal preference and not only locale dependent. If Windows XP only adhere to the users choice of 12H/24H format for the current system locale and uses other formats for other locales, that might be considered a bug in Windows XP. I haven't tested if that is the case.

Other applications do follow the os defaults for time/date. No way users would prefer to enter and read dates backwards just because they happen to use the en-US version of the software. (Which many people do, due to various reasons.)

Bug 441167 made nsIScriptableDateFormat default to the application locale, which is set by the general.useragent.locale. So a workaround is to set that pref to your desired locale, like "de". I didn't notice any unwanted side-effects other than, well, changing your user agent sent via HTTP, SMTP, etc.

(In reply to comment #15) > Other applications do follow the os defaults for time/date. No way users would > prefer to enter and read dates backwards just because they happen to use the > en-US version of the software. (Which many people do, due to various reasons.) ++. There's no en-IN version of any Mozilla product, and I definitely wouldn't want to see dates backwards by default in my calendar application. In my understanding, at least on Windows, if you ask for the same locale as the locale set in Regional and Language Options, you'll get the user-customized format. Otherwise you'll get the default format. (In reply to comment #16) > Bug 441167 made nsIScriptableDateFormat default to the application locale, > which is set by the general.useragent.locale. So a workaround is to set that > pref to your desired locale, like "de". > > I didn't notice any unwanted side-effects other than, well, changing your user > agent sent via HTTP, SMTP, etc. While this works, I'd rather see this as a proper option than a hidden pref. Maybe something like "Use <App Locale/OS Locale> to format dates and times"?

We can't expect users to jump through (hacky) hoops to enable the behavior they all need - if they have to, then our code is broken. You're effectively making the user OS setting not apply. Why do you expect it's there in the first place? Time and date is /the/ use case for it. The OS setting is easily settable, and OS:s have UI for it. If people want en-US time/date, that's just a click away.

I see three possibilities: - accept the behavior and fix the remaining places with Bug 399605 or - file a Toolkit bug and convince them to revert Bug 441167 or - file a Toolkit bug and convince them to make the behavior configurable

The use case in Bug 441167 is for using en-US apps on Danish Windows. Although I can understand that some folks would want that to default to en-US style dates, personally, I think it should default to the OS settings, but provide the user with a switch to say use the locale settings. I would expect that in the vast majority of cases users will expect the application to display dates the same as all the other applications on their system - i.e. via the OS settings (regardless of language in use). I also think that using general.useragent.locale as a tweak is not an option because of the way it affects user-agents. IMHO we should be asking toolkit (and locale owners) for a discussion and maybe a use OS versus locale option.

I just checked this on Vista. When I customize both the Danish locale and the English locale in "Regional and Language Options", only the customizations of the currently default locale is saved. This seems to be a bug in Windows we have to live with. I suspect we can discuss this issue forever. I can live with using the OS locale, through i don't like it. However if we do that, it should be consistent. Having a date displayed as "1/2/2008" in one place in the application and the same date displayed as "2/1/2008" in another part of the application would IMHO not be good. The reason I filed bug 441167 was because of bug 419220 which makes labels in the download manager mixed language which sometimes make them unreadable. So I guess there are two ways to go if we should use the OS locale: 1) Ship custom date formatting code for all locales in each locale. This could be complex. 2) Do not use custom date formatting at all. This would include loosing the compact date display in the Download Manager where only the most relevant part is shown. The UI would be more crowded there. But what about time ranges? The OS does not support these, so for the "time left" labels, it would have to be in the application locale while "time finished" would be in the OS locale. I guess Lightning also has some custom date display which should be changed. No matter what, the APIs and their pitfalls should be documented in the IDL files and possibly MDC so that we hopefully won't see bugs like bug 419220 again.

I think form user perspective the optimal version would be just respect OS settings. If that is too hard to realize offer Lightning-specific customization in the settings. (I'm one of the users using mostly english programs, on some boxes even english OS versions but with german settings for date/time display ... all other applications i checked did respect OS setting for date/time format.)

Please, don't change the QA contact!

The change from bug 441167 has been backed out on 1.9.1 branch (bug 441167 comment #21). Dates should be shown in OS format again.

Marking FIXED per previous comment.

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".