[calendar] ICAL parser correctly handle timezones

VERIFIED FIXED in B2G C3 (12dec-1jan)

Status

Firefox OS
Gaia::Calendar
P1
normal
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: GH to BZ, Assigned: lightsofapollo)

Tracking

unspecified
B2G C3 (12dec-1jan)

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: [label:calendar][label:feature][interaction][LOE:S][target:12/21])

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
[GitHub issue by lightsofapollo on 2012-08-09T00:57:36Z, https://github.com/mozilla-b2g/gaia/issues/3279]
Seems like upstream in ICAL.js we do not convert the event. Should happen there or in gaia so free-busy times reflect the current timezone.
(Reporter)

Comment 1

5 years ago
[GitHub comment by autonome on 2012-08-20T15:54:45Z]
Re-assign as needed.
(Reporter)

Comment 2

5 years ago
[GitHub comment by lightsofapollo on 2012-09-26T08:15:57Z]
db support has landed, ICAL.js can now parse timezone information needs final hookup.
(Assignee)

Updated

5 years ago
Component: Gaia → Gaia::Calendar

Updated

5 years ago
Priority: -- → P2
Created attachment 673437 [details]
screenshot - bad timezone

Attaching screenshot of incorrect calendar entries. 

The two long meetings shown in the screenshot ("Review session for basecamp...") are scheduled for 10am Pacific, but the invites were sent from DavidS in Paris and they are showing up in the calendar for 7pm instead (Paris time).
This was previous approved blocking+/P2 -- I'm re-nominating for P1 consideration as calendar would become much less useful for anyone working with multiple timezones.
blocking-basecamp: + → ?
blocking-basecamp: ? → +
Priority: P2 → P1
In Settings and FTU App we have the same issue... We should have a common way of showing the same timezones. What do you think about creating a 'timezones.json' in '/Shared' for having the same list ("GMT +2 Bucharest, Cairo..." for example should be the same in all apps).
This could be useful until having https://bugzilla.mozilla.org/show_bug.cgi?id=714357 fixed.
Could we rename this bug as 'Getting a set of right timezones in Gaia Apps'? Thanks!
We considered using a `shared/resources/` directory to host timezones.json, apns_conf.xml, ringtones, etc. The only difficulty would be related to the build system: in order to know which shared resources should be imported in an app, we should have a reference to it in a <link /> element, like we do for locales.

  <link rel="resource" href="timezones.json" />

If you open a bug like “use a shared/resources/ directory in Gaia”, I’ll happily submit a patch. That being said, I don’t know if that will solve your timezone issues in particular — I’ll trust you on that.
Great! I've created the following bug https://bugzilla.mozilla.org/show_bug.cgi?id=803029 . Thanks [:kaze] !

Updated

5 years ago
Priority: P1 → --

Updated

5 years ago
Priority: -- → P3

Updated

5 years ago
Whiteboard: [label:calendar][label:feature] → [label:calendar][label:feature][interaction]
This bug hasn't moved in over a month. What needs to be done to close this?
(Assignee)

Comment 9

5 years ago
The above discussions don't effect this bug calendar (ical) contains the timezone information we can storage it, parse it and use it but there is a bug in the ical parser. Same deal here P3 = bottom of queue. With the new ical parser design this should be much easier.

This is marked as a "feature" which I believe is incorrect? We simply parse the information sent from the server and use it to offset the position of the event in time relative to the UTC offset in the current timezone.
Summary: [calendar] Correctly handle timezones → [calendar] ICAL parser correctly handle timezones
Whiteboard: [label:calendar][label:feature][interaction] → [label:calendar][label:feature][interaction][LOE:S]

Updated

5 years ago
Target Milestone: --- → B2G C3 (12dec-1jan)

Updated

5 years ago
Duplicate of this bug: 817411
Renoming - This was previously a P2, then a P1, now a P3. If we compare the list of bugs for calendar, you'll this clearly does not fit into a P3 bucket because:

Pretty much every P3 is either some usability issue, perf issue, or corner case with reoccurring events. This bug basically basic functionality bustage for timezone-based events - an example I hit was someone in Toronto created an event at 12pm. I see the event at 12pm as well, but that's wrong - it should be 9am.

It also doesn't feel like a P2 either - the P2s cited are about network failures. This is basic bustage with timezones.

I'm arguing P1.
blocking-basecamp: + → ?
Priority: P3 → --
(Assignee)

Comment 12

5 years ago
Casey, where do we want the UI for timezones? I assume we would want to show which timezone an event is in? For v1 this needs to be read only but we should make it clear in which event it occurs, correct?
(Assignee)

Comment 13

5 years ago
This has performance impact as well as our recurring rule expansion is very slow. Its possible that we slow sync to a crawl. I am going to do an initial test to see what the relative performance is with the current timezone/recurring expansion implementation.

See bug 817796 for details of optimizing recurring event expansion.
blocking-basecamp: ? → +
Priority: -- → P1
Whiteboard: [label:calendar][label:feature][interaction][LOE:S] → [label:calendar][label:feature][interaction][LOE:S][target:12/21]
(Assignee)

Comment 14

5 years ago
My priority is to handle this in the backend, we currently don't have a spot to display this to the user. Thoughts?
Flags: needinfo?(kyee)
(Assignee)

Comment 15

5 years ago
Progress is being made here. I have an initial working version but the performance of the original recurring event implementation and timezone offset calculations where very slow.

I did a first pass on recurring events (with about 7x speedup there) and now working on timezone offsets. An acceptably fast version (should hopefully speed up overall sync) should be ready tomorrow afternoon (Dec/13)
(Assignee)

Comment 16

5 years ago
Created attachment 691979 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7005

Pointer to Github pull-request
(Assignee)

Comment 17

5 years ago
Comment on attachment 691979 [details]
Pointer to Github pull request: https://github.com/mozilla-b2g/gaia/pull/7005

I volunteered Kevin to review some the underlying ICAL.js patches that make this work. Those must be reviewed independently before we can migrate the code over to gaia. 

Performance on the device has yet to be measured, If possible I want this patch to improve overall sync performance. Failing that we must at least even out.

I have some measurement tools I will use to compare shortly...
Attachment #691979 - Flags: review?(kgrandon)

Comment 18

5 years ago
I have added a timezone section to the new/edit event screens.

Updated wireframes here:
https://www.dropbox.com/s/31j9d4qrp2v08ny/calendar-events.pdf
Flags: needinfo?(kyee)
(Assignee)

Comment 19

5 years ago
Hey Casey,

These look good but what about the case where start timezone is different then end timezone? (Start in PST end in EST, etc...).

I am tempted to move the display part out of this bug if we can all agree that is blocking. We should land the back-end functionality ASAP so we can have some people start testing it.
Flags: needinfo?(kyee)
(Assignee)

Comment 20

5 years ago
Current implementation syncs 32% faster then the previous (in addition to handling timezones). Times measured by the progress indicators presence with marionette.

Each run was executed 3 times (turn on calendar, sync, remove account, sync, etc..).
Each group was executed twice on a clean flash.

I have not yet measured memory improvements but I suspect there are some.
Attachment #691979 - Flags: review?(kgrandon) → review+
(Assignee)

Comment 21

5 years ago
One problem remains which is when the timezone is changed calendar needs to restart itself...
(Assignee)

Comment 22

5 years ago
We now handle the above case and refresh calendar when timezone changes on the device.

We need a followup bug to handle some UI/UX aspects I will post it shortly.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
Keywords: verifyme
QA Contact: jsmith

Updated

5 years ago
Flags: needinfo?(kyee)
Verified at a sanity level by using my personal google calendar in the Berlin timezone - events came up at the right time and were listed correctly.
Status: RESOLVED → VERIFIED
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.