Some timezones not mapped correctly

RESOLVED FIXED in 0.9

Status

defect
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: cmtalbert, Assigned: gekacheka)

Tracking

unspecified
Dependency tree / graph
Bug Flags:
wanted-calendar0.9 +

Details

Attachments

(3 attachments)

Reporter

Description

12 years ago
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
Flags: blocking-calendar0.8?
Flags: blocking-calendar0.8? → wanted-calendar0.8+
Reporter

Comment 1

12 years ago
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

Comment 2

12 years ago
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.
Assignee

Comment 3

12 years ago
(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 ...")

Comment 4

12 years ago
TB Versie 2.0.0.9 (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).

Comment 5

12 years ago
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.

Comment 7

12 years ago
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

Comment 8

12 years ago
OS: Mac OS X 10.4.11 
TB: 2.0.0.9 (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.
Assignee

Comment 10

12 years ago
(patch -l -p 1 -i file.patch)

Thanks for catching this (comment 1).
Attachment #302426 - Flags: review?(ctalbert)
Assignee

Comment 11

12 years ago
(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)
Assignee

Comment 12

12 years ago
> 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
Reporter

Comment 13

12 years ago
Comment on attachment 302426 [details] [diff] [review]
[checked in] patch winnt data: Yakutskd -> Yakutsk

looks good, r=ctalbert
Attachment #302426 - Flags: review?(ctalbert) → review+
Reporter

Comment 14

12 years ago
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+
Reporter

Comment 15

12 years ago
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?
Reporter

Updated

12 years ago
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
Reporter

Updated

12 years ago
Attachment #302426 - Attachment description: patch winnt data: Yakutskd -> Yakutsk → patch winnt data: Yakutskd -> Yakutsk - checked in
Target Milestone: --- → 0.8
Clint, this checkin caused a string update in calendar.properties, I don't think this was intended this late in the game?
Keywords: late-l10n
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
Assignee

Comment 18

12 years ago
(patch -l -p 1 -i file.patch)
Attachment #303863 - Flags: review?
Assignee

Updated

12 years ago
Attachment #303863 - Flags: review? → review?(ctalbert.moz)
Assignee

Comment 19

12 years ago
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
Reporter

Comment 21

12 years ago
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)
Status: NEW → ASSIGNED
Reporter

Comment 22

12 years ago
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+
Flags: wanted-calendar0.8+ → wanted-calendar0.9+
Attachment #302426 - Attachment description: patch winnt data: Yakutskd -> Yakutsk - checked in → [checked in] patch winnt data: Yakutskd -> Yakutsk
Keywords: late-l10n
OS: Mac OS X → All
Hardware: Macintosh → All
Whiteboard: [checkin-needed after 0.8] - applies to attachment 302428 → checkin-needed
Keywords: checkin-needed
Whiteboard: checkin-needed
Both remaining patches checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
You need to log in before you can comment on or make changes to this bug.