Closed Bug 379462 Opened 13 years ago Closed 13 years ago
Changing timezone of event in various timezones isn't possible
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.
Attachment #263467 - Flags: review?(daniel.boelzle)
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.
Attachment #263467 - Flags: review?(daniel.boelzle) → review+
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.
(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.
Status: NEW → ASSIGNED
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).
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.
(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.
Severity: normal → critical
Summary: [Proto] Changing timezone of event to America/Buenos_Aires isn't possible → Changing timezone of event in various timezones isn't possible
Whiteboard: [l10n impact]
Target Milestone: --- → Lightning 0.5
Version: Trunk → unspecified
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.
(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.
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.
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?
Priority: -- → P1
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.
Flags: blocking-calendar0.5? → blocking-calendar0.5+
Whiteboard: [l10n impact] → [l10n impact] [checkin needed]
patch checked in on trunk and MOZILLA_1_8_BRANCH -> FIXED
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [l10n impact] [checkin needed] → [l10n impact]
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?
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...
I checked this issue in the latest nightly build (2007050805) with en_US locale, at windows and linux. Task is fixed.
Verifed on lightning o.5 RC1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.