543 bytes, patch
|Details | Diff | Splinter Review|
915 bytes, patch
|Details | Diff | Splinter Review|
1.58 KB, patch
|Details | Diff | Splinter Review|
TODO: Need testing to see if these are guessed properly on other OS's. On Mac, if you set these timezones to these zones, and then you restart the Calendar (Sunbird or lightning) with a new profile, the zones are not guessed properly. == Actual == Asia/Jerusalem --> gets guessed as "floating" Australia/Adelaide --> gets guessed as "floating" Australia/Sydney --> gets guessed as Australia/Currie == Expected == Asia/Jerusalem --> Asia/Jerusalem Australia/Adelaide --> Australia/Adeliade Australia/Sydney --> Australia/Sydney
Also, Martin Schroeder found this on windows: From WindowsNTToZoneInfoTZId.properties: Yakutsk Standard Time: Asia/Yakutskd should be Yakutsk Standard Time: Asia/Yakutsk I'm going to make this a catch-all bug for these sorts of minor mis-mappings stemming from the fix for bug 328996
Depends on: 328996
Summary: Some timezones are not guessed properly on Mac → Some timezones not mapped correctly
I'm not getting a correct guess here for Pacific/Auckland with the latest nightly 1.8 In my logs I see: Warning: Operating system timezone "/etc/timezone: Pacific/Auckland" no longer matches ZoneInfo timezone "Pacific/Auckland". Warning: Using "floating" timezone. No ZoneInfo timezone data matched the operating system timezone data. This could be either of two issues: NZ changed the daylight saving time definitions earlier this year (the Olsen database is up to date, and so is my OS). We're also currently in daylight savings and GMT +13, which sometimes surprises programmers from other parts of the world, but I doubt if that's the problem in this case. Also, this is on Debian Sid, FWIW. Regards, Andrew McMillan.
(In reply to comment #2) > NZ changed the daylight saving time > definitions earlier this year (the Olsen database is up to date, and so is my > OS). > Your OS zoneinfo database may be up to date, but the the internal data used by sunbird and lightning was last updated Jan 2007. Bug 410931 will update the internal data. (todo: Make this warning clearer, maybe by adding 'the internal' in the warning "... no longer matches the internal ZoneInfo timezone ...")
TB Versie 22.214.171.124 (20071031) / Lightning 0.8pre - 2008012320 Europe/Amsterdam/Berlin/Bern (GMT+1) is recognized as Europe/Berlin instead of Europe/Amsterdam. The definition is the same across this part of Europe so no big deal. However, if I open the event-dialog of a remote event in an ics-calendar it shows UTC (event created with Outlook-2000 so foreign timezone probably) but when I open the timepicker from the event-dialog it says Europe-Berlin again (which is actually a good thing to do but which it isn't meant to be doing).
At Windows XP some timezones doesn't fit to Lightning timezones. OS timezone is 'Alaska' -> timezone in lightning is set to 'Africa/Abidjan' (first entry in the lightning timezone list) and not America/Anchorage. Same when OS timezone is 'International Date Line West' -> lightning shows again 'Africa/Abidjan'.
Could you check the Error Console what timezone is guessed? Ir I recall correctly "floating" is used if no timezone matches. But the timezone list in the preference dialog has no entry "floating". Therefore the first entry is selected by default.
Sorry, my comment #5 is based on build 20080124. I checked this now with the latest build (20080127) and if the OS timezone is 'Alaska' now the timezone of events in lightning is 'floating'. Output Error Console: Error: menuitem has no properties Source File: chrome://calendar/content/sun-calendar-event-dialog-timezone.js Line: 81
OS: Mac OS X 10.4.11 TB: 126.96.36.199 (20071031) Lightning: 0.8pre (2008020621) My Timezone: Europe/Berlin Guessed Timezone: Europe/Paris Not a big deal ... but - not correct ;-) Here the infos from Error-Console: Warning: Using guessed timezone /mozilla.org/20070129_1/Europe/Paris (UTC+0100/+0200). This ZoneInfo timezone seems to match the operating system timezone this year. This ZoneInfo timezone was chosen based on matching the operating system timezone with likely timezones for internet users using US English. Jochen
(In reply to comment #8) > This ZoneInfo timezone seems to match the operating system timezone this year. > This ZoneInfo timezone was chosen based on matching the operating system > timezone with likely timezones for internet users using US English. As I understand it this will work, once you use a German version of Lightning.
(patch -l -p 1 -i file.patch) Thanks for catching this (comment 1).
Attachment #302426 - Flags: review?(ctalbert)
(patch -l -p 1 -i file.patch) Clarify error message, since OS may have different version of ZoneInfo timezone data installed (comment 2 and comment 3).
Attachment #302428 - Flags: review?(ctalbert)
> Asia/Jerusalem (comment 0) > Australia/Adelaide (comment 0) > Pacific/Aukland (comment 2, comment 3) I hope these will be fixed when the calendar ZoneInfo data is updated in bug 410931. > Paris vs. Amsterdam vs. Berlin (comment 4, comment 8) These all currently share the same offset and daylight/summer time changes, so it guesses the same for each. As hinted in comment 9, this can be overridden per language by a localization hint. > Australia/Sydney --> gets guessed as Australia/Currie (comment 0) I was not able to reproduce this guess (I get Australia/Melbourne). (My old w2k is not MacOSX; maybe MacOSX data for Sydney is different?). > Alaska --> floating (comment 7) I was not able to reproduce this problem. Guesses America/Anchorage. Maybe timezone data is different, or daylight time turned off? > International dateline west --> floating (comment 5) There is no ZoneInfo data for this artificial timezone. (Maybe all islands near the dateline would rather be in the first timezone rather than the last, for example to attract tourists, and Alaskan timezones seem to be synchronized to their suppliers in Anchorage. Historically it may have been important for US territories supplied via Hawaii.) http://en.wikipedia.org/wiki/List_of_time_zones#UTC.E2.88.9212.2C_Y
Comment on attachment 302426 [details] [diff] [review] [checked in] patch winnt data: Yakutskd -> Yakutsk looks good, r=ctalbert
Attachment #302426 - Flags: review?(ctalbert) → review+
Comment on attachment 302428 [details] [diff] [review] patch en-US: no longer matches *the internal* ZoneInfo timezone r=ctalbert
Attachment #302428 - Flags: review?(ctalbert) → review+
Checked in attachment 302426 [details] [diff] [review] and attachment 302428 [details] [diff] [review] on trunk and branch. I have also rechecked my australia problem. Now, it's guessing Hobart instead of Sydney. It turns out that Currie, Hobart and Sydney all have the same offset, and same DST schedule. This is going to have to be something solved by a localization function in the properties file. I don't want to mark it fixed until we hear from the other two "floating" timezone issues that were noted: Alaska --> Floating (comment 7) and Intl Date Line --> Floating (comment 5). Are these still reproducible, should we file follow on bugs for this, or should we take more patches here?
Attachment #302428 - Attachment description: patch en-US: no longer matches *the internal* ZoneInfo timezone → patch en-US: no longer matches *the internal* ZoneInfo timezone - checked in
Attachment #302426 - Attachment description: patch winnt data: Yakutskd -> Yakutsk → patch winnt data: Yakutskd -> Yakutsk - checked in
Clint, this checkin caused a string update in calendar.properties, I don't think this was intended this late in the game?
Clint, please backout the string change in calendar/locales/en-US/chrome/calendar/calendar.properties We're in string freeze and such changes should not go in that late in the game.
Assignee: nobody → gekacheka
(patch -l -p 1 -i file.patch)
Attachment #303863 - Flags: review?
Attachment #303863 - Flags: review? → review?(ctalbert.moz)
If "International Dateline West (-1200)" is really needed (inhabited tropical islands in the region use UTC+1200 rather than UTC-1200; the US tropical islands are uninhabited; the Aleutians appear to use America/Anchorage), Then the calendar ZoneInfo database will have to be augmented to include Etc/GMT-1200. If this is done, consider putting the Etc/ timezones at the *end* of the .timezoneIds enumeration, so that they are considered after any timezones of human settlements. (If they cannot be listed at the end, then guessSystemTimezone will have to be modified to check for "Etc/" timezones in the enumeration, and use one only if no non-Etc timezones match.)
Comment on attachment 302428 [details] [diff] [review] patch en-US: no longer matches *the internal* ZoneInfo timezone I reverted the change made in attachment 302428 [details] [diff] [review]. This will have to be checked in after 0.8 is out.
Attachment #302428 - Attachment description: patch en-US: no longer matches *the internal* ZoneInfo timezone - checked in → patch en-US: no longer matches *the internal* ZoneInfo timezone
Whiteboard: [checkin-needed after 0.8] - applies to attachment 302428
Thanks for backing that out, Simon. I thought it was ok since it is not a translated string but a direction for the timezone guessing code. But, whatever.
Target Milestone: 0.8 → ---
Attachment #303863 - Flags: review?(ctalbert.moz) → review?(ctalbert)
Comment on attachment 303863 [details] [diff] [review] patch en-US: Australia/Sydney likelier than Australia/Currie or Australia/Hobart Patch https://bugzilla.mozilla.org/attachment.cgi?id=303863 Can we take this? It's not a "real" string change, though it is a change to the property file. It's a direction change for the timezone guessing software and I think we really ought to take it, even if we have to consider it Late L10N. Since it would just be a copy/paste for localizers (no translation required) I think it would make sense to take it. r=ctalbert
Attachment #303863 - Flags: review?(ctalbert) → review+
Attachment #302426 - Attachment description: patch winnt data: Yakutskd -> Yakutsk - checked in → [checked in] patch winnt data: Yakutskd -> Yakutsk
OS: Mac OS X → All
Hardware: Macintosh → All
Whiteboard: [checkin-needed after 0.8] - applies to attachment 302428 → checkin-needed
Both remaining patches checked in on HEAD and MOZILLA_1_8_BRANCH -> FIXED
You need to log in before you can comment on or make changes to this bug.