379462 - Changing timezone of event in various timezones isn't possible

Status: VERIFIED FIXED

(Calendar :: General, defect, P1)

Description

[Andreas Treumann]

REPRODUCTION:
=============

- create an event
- open the new event dialog
- enable Options/Timezone 
- open the timezone dialog
- choose America/Buenos_Aires
- save this

RESULT:
=======

- the event isn't switched to the timezone 'America/Buenos_Aires'
- the event dialog shows 'floating' instead 'America/Buenos_Aires'

EXPECTED RESULT:
================

- the timezone of this event should be 'America/Buenos_Aires

REPRODUCIBLE:
=============

- always


Javascript Console
==================

Error: uncaught exception: [Exception... "Component returned failure code: 0x804a0001 [calIICSService.getTimezone]"  nsresult: "0x804a0001 (<unknown>)"  location: "JS frame :: chrome://calendar/content/sun-calendar-event-dialog-timezone.js :: updateTimezone :: line 118"  data: no]

Comment 1

[Michael Büttner (no reviews TFN)]

Attachment: patch v1

I'm not sure why the list of timezones was again out-of-sync. This list now has been automatically generated from the list in tzdata. Daniel, please have a look on it, just to make sure that I didn't miss anything.

Comment 2

[Daniel Boelzle [:dbo]]

Comment on attachment 263467 [details] [diff] [review]
patch v1

No, I won't double check all entries... ;-) I assume you figured out the diff programmatically; r=dbo.

Comment 3

[Stefan Sitter [:ssitter]]

You are changing m/c/locales/en-US/chrome/calendar/preferences/timezones.dtd. It seems that this will also effect the Sunbird and Lightning preferences dialog because you also remove used entities and add new ones.

Is this (the missing/wrong timezones in preferences) a fallout from the 0.3.1 timezone update? If yes this probably also exists since 0.3.1 without being noticed.

Now is the question: Is this a blocker for 0.5? If yes it has major impact on l10n.

Comment 4

[Michael Büttner (no reviews TFN)]

(In reply to comment #3)
> You are changing m/c/locales/en-US/chrome/calendar/preferences/timezones.dtd.
> It seems that this will also effect the Sunbird and Lightning preferences
> dialog because you also remove used entities and add new ones.
Right, I'll add the necessary changes to the preference dialog, thanks for pointing this out.

I still don't know why the timezones in tzdata and timezones.dtd (and the relevant bits and pieces) are out-of-sync. But I just double-checked that this indeed has a major impact. Just set the lightning/sunbird timezone to Buenos Aires and note that newly created events end up as floating. I'd nominate this for blocking 0.5. Updated patch follows ASAP.

Comment 5

[Michael Büttner (no reviews TFN)]

Attachment: patch v2

This patch also takes care of the timezone-list on the preference dialog, which is basically the same as the one in the timezone-picker (that's why i carried over the r+ flag).

Comment 6

[Andreas Treumann]

I checked this issue in lightning 0.3.1. The timezone-picker shows the .../America/Argentina/Buenos_Aires entry and the timezone switch is possible.
So this bug is a regression.

Comment 7

[Simon Paquet [:sipaq]]

(In reply to comment #6)
> I checked this issue in lightning 0.3.1. The timezone-picker shows the
> .../America/Argentina/Buenos_Aires entry and the timezone switch is possible.
> So this bug is a regression.

Andreas,
looking at the branch checkins on January 30st

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=mozilla%2Fcalendar&sortby=Date&date=explicit&mindate=2007-01-30+13%3A00%3A01&maxdate=2007-01-30+14%3A00%3A00&cvsroot=%2Fcvsroot

it seems that the timezones in tzdata.c and timezones.dtd were out-of-sync even before the 0.3.1 release, because even the old 2005 timezones has entries like 
"/mozilla.org/20050126_1/America/Argentina/Buenos_Aires" for Buenos Aires, which weren't reflected in timezones.dtd.

Did you test a stock 0.3.1 Lightning or the enhanced Sun-version? If the latter, did the Sun version perhaps hardcode some strings into the prototype dialog?

Raising severity and CC'ing lilmatt, because this bug is a serious blocker for people using our software in the affected timezones on branch and trunk. In addition this bug has l10n impact.

Comment 8

[Andreas Treumann]

I checked this with the released 0.3.1 builds from http://addons.mozilla.org/thunderbird/2313 (lightning without wcap) and from http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/0.3.1/lightning-wcap/

In both cases the timeszone switch works for me. 

Comment 9

[Stefan Sitter [:ssitter]]

(In reply to comment #8)
Lightning 0.5pre shares the preferences dialog code with Sunbird. Lightning 0.3.1 used to have a separate implementation. This was merged with Bug 372014.

Comment 10

[Stefan Sitter [:ssitter]]

If it will be decided that this must be fixed for 0.5 we also need to decide if this should be done with or without l10n impact. 

The solution without l10n impact would be to just hard code the new strings into the xul and add them to the .dtd after release. IIRC we have done this for a previous release too.

Comment 11

[Simon Paquet [:sipaq]]

I'm marking this bug late-l10n, to make localizers aware that something *may* be coming down their way.

IMO we should

- take the patch from Mickey.
- give localizers 4-5 days to fix their respective timezones.dtd file.
- In case someone is not able to do this, we fix the respective timezones.dtd 
  file, by putting in the English strings.

Comments?

Comment 12

[Simon Paquet [:sipaq]]

After a mail discussion with lilmatt he said, that he is fine, with whatever the majority decides.

After discussion with daniel, he and I agree with mickey, that this is serious enough to take it for 0.5.

Comment 13

[Michael Büttner (no reviews TFN)]

patch checked in on trunk and MOZILLA_1_8_BRANCH

-> FIXED

Comment 14

[Stefan Sitter [:ssitter]]

Do we also need an update strategy for users that configured Sunbird/Lightning to a no longer existing timezone, e.g. "/mozilla.org/20070129_1/Asia/Macao"? 
Or should we just release note this fact and ask users to check the timezone preference after upgrade to 0.5?

Comment 15

[Michael Büttner (no reviews TFN)]

This is exactly what bug #314339 takes care of, but since we decided to go ahead without it for 0.5, I think we need to add a release note and leave it as it is for now. That's unfortunate, but probably the best we can do for now...

Comment 16

[Andreas Treumann]

I checked this issue in the latest nightly build (2007050805) with en_US locale, at windows and linux. Task is fixed.

Comment 17

[Omar Bajraszewski]

Verifed on lightning o.5 RC1