Closed Bug 444713 Opened 16 years ago Closed 16 years ago

Allow providers to provide a set of supported timezones

Categories

(Calendar :: General, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: dbo, Assigned: dbo)

Details

Attachments

(1 file)

If particular calendar systems don't support our full local set of timezones, they should have the possibility to provide a set of supported timezones offered in the event dialog.
Attached patch patch - v1Splinter Review
Attachment #329032 - Attachment is patch: true
Attachment #329032 - Attachment mime type: application/octet-stream → text/plain
Comment on attachment 329032 [details] [diff] [review]
patch - v1

- adds calendar property "timezones.provider" and "timezones.floating.supported"
- implements them for wcap
Attachment #329032 - Flags: review?(philipp)
Assignee: nobody → daniel.boelzle
Status: NEW → ASSIGNED
Comment on attachment 329032 [details] [diff] [review]
patch - v1

>-    // don't rely on what order the timezone-service gives you
>     while (enumerator.hasMore()) {
Do we now want to rely on the tz service sorting the timezone ids? Or should we use binaryInsert() (not sure thats in the tree yet, its in my alarms patch I believe) to make sure the items are sorted (Using the locale collator too)

>+            case "timezones.provider":
>+                return ((this.m_session && this.session.isLoggedIn) ? this.session : null);
>+            case "timezones.floating.supported":
>+                return false;
What do you suggest I do for gdata here? I do have a timezones provider for gdata, but it only translates Europe/Berlin to our mozilla prefixed timezones. I will need to set timezones.floating.supported to false, but enumerating the timezones is untested, I believe I return the timezone service's enumerator.

r=philipp, it would be great if you could also patch gdata, otherwise I'll attach a patch after my question was answered ;-)
Attachment #329032 - Flags: review?(philipp) → review+
(In reply to comment #3)
> (From update of attachment 329032 [details] [diff] [review])
> >-    // don't rely on what order the timezone-service gives you
> >     while (enumerator.hasMore()) {
> Do we now want to rely on the tz service sorting the timezone ids? Or should we
> use binaryInsert() (not sure thats in the tree yet, its in my alarms patch I
> believe) to make sure the items are sorted (Using the locale collator too)
The TZIDs are irrelevant, no sorting assumed here. What needs to be sorted are the calITimezone::displayNames, and that's done by the UI code after collecting all display names.

> >+            case "timezones.provider":
> >+                return ((this.m_session && this.session.isLoggedIn) ? this.session : null);
> >+            case "timezones.floating.supported":
> >+                return false;
> What do you suggest I do for gdata here? I do have a timezones provider for
> gdata, but it only translates Europe/Berlin to our mozilla prefixed timezones.
We don't have timezone prefixes anymore... we use the plain Olson names now.

> I will need to set timezones.floating.supported to false, but enumerating the
> timezones is untested, I believe I return the timezone service's enumerator.
Floating as well as UTC are special, there are no TZIDs returned with the enumerator (I am not aware that either "floating" or "UTC" is a valid TZID). We still keep "floating" and "UTC" resolvable via getTimezone though, for compat purposes.
So the timezone service just enumerates the plain (unaliased) timezone definitions it knows, excluding floating and UTC.
BTW: For completeness we could also add "timezones.UTC.supported", but hey, I assume every calendar supports that ;)

> r=philipp, it would be great if you could also patch gdata, otherwise I'll
> attach a patch after my question was answered ;-)
This is just a drive-by patch lying around for a while, it's not really important for the upcoming release...
(In reply to comment #3)
> >+            case "timezones.provider":
> >+                return ((this.m_session && this.session.isLoggedIn) ? this.session : null);
> >+            case "timezones.floating.supported":
> >+                return false;
> What do you suggest I do for gdata here? I do have a timezones provider for
> gdata, but it only translates Europe/Berlin to our mozilla prefixed timezones.
I am not sure whether gdata should return a timezones.provider at all. IIRC you are storing timezones by offset only, there's no distinct timezone definition. So you right could support all of our Olson definitions, right?
Checked in on HEAD and MOZILLA_1_8_BRANCH => FIXED.

Philipp, please reopen if you want to add code for gdata, or handle that in a different bug.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Target Milestone: --- → 0.9
Verified in lightning 2008080603 and sunbird 20080805 -> VERIFIED.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.