413265 - Some timezones not mapped correctly

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[cmtalbert]

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

Comment 1

[cmtalbert]

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

Comment 2

[Andrew McMillan]

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.

Comment 3

[gekacheka]

(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

[Bas van den Bosch]

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

[Andreas Treumann]

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'.

Comment 6

[Stefan Sitter [:ssitter]]

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

[Andreas Treumann]

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

[Jochen Grotepass]

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

Comment 9

[Sebastian Schwieger]

(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.

Comment 10

[gekacheka]

Attachment: [checked in] patch winnt data: Yakutskd -> Yakutsk

(patch -l -p 1 -i file.patch)

Thanks for catching this (comment 1).

Comment 11

[gekacheka]

Attachment: patch en-US: no longer matches *the internal* ZoneInfo timezone

(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).

Comment 12

[gekacheka]

> 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 13

[cmtalbert]

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

looks good, r=ctalbert

Comment 14

[cmtalbert]

Comment on attachment 302428 [details] [diff] [review]
patch en-US: no longer matches *the internal* ZoneInfo timezone

r=ctalbert

Comment 15

[cmtalbert]

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?

Comment 16

[Philipp Kewisch [:Fallen][📱📆]]

Clint, this checkin caused a string update in calendar.properties, I don't think this was intended this late in the game?

Comment 17

[Simon Paquet [:sipaq]]

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.

Comment 18

[gekacheka]

Attachment: patch en-US: Australia/Sydney likelier than Australia/Currie or Australia/Hobart

(patch -l -p 1 -i file.patch)

Comment 19

[gekacheka]

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 20

[Simon Paquet [:sipaq]]

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.

Comment 21

[cmtalbert]

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.

Comment 22

[cmtalbert]

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

Comment 23

[Philipp Kewisch [:Fallen][📱📆]]

Both remaining patches checked in on HEAD and MOZILLA_1_8_BRANCH

-> FIXED