Closed
Bug 321913
Opened 17 years ago
Closed 17 years ago
alarm service's mRangeEnd needs to be more timezone sensitive (causes alarms not to fire in some timezones, like GMT+8)
Categories
(Calendar :: Internal Components, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: spam1, Assigned: jminta)
References
Details
Attachments
(1 file)
1.57 KB,
patch
|
dmosedale
:
first-review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051227 Mozilla Sunbird/0.3a1+ After adding any type of item (event or task), and setting up an alarm (popup), nothing happens. Reproducible: Always Steps to Reproduce: 1. create an event (either in the past or future) 2. setup a popup alarm and validate 3. nothing happens Actual Results: nothing happens Expected Results: alarm should be triggered same bug is seen with home built source, 0.3a1, and nightly build version. the problem seems related to addItem function, more specifically getInTimeZone() function in calAlarmService.js, in the components/ directory.
I am located in China/Shanghai (GMT+8) which might help in understanding the timezone issue.
Version: unspecified → Trunk
Assignee | ||
Comment 2•17 years ago
|
||
Confirming (and updating summary). The problem is that mRangeEnd isn't sensitive to the user's timezone. In this case (from IRC), mRangeEnd is too early. Basic scenario for adding an alarm in GMT+8: alarmTime: 23:59 UTC (from getInTimezone("UTC")) now: 23:55 Floating this.mRangeEnd: 21:45 UTC I can fix this by replacing this.mRangeEnd with (now+6 hours) in the if block at http://lxr.mozilla.org/mozilla/source/calendar/base/src/calAlarmService.js#333 but I'm not sure that that is the correct solution.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: alarms don't work at all → alarm service's mRangeEnd needs to be more timezone sensitive (causes alarms not to fire in some timezones, like GMT+8)
Updated•17 years ago
|
Blocks: lightning-0.1
Assignee | ||
Comment 3•17 years ago
|
||
This patch works with the duration remaining until we do a refresh, rather than with the actual time. That avoids timezone issue. Tested with several different timezones and things seemed to work well.
Comment 4•17 years ago
|
||
Comment on attachment 208709 [details] [diff] [review] patch v1 A few llines up in the source, we see: // XXX When the item is floating, should use the default timezone // from the prefs, instead of the javascript timezone (which is what // from the prefs, instead of the javascript timezone (which is what // jsDateToFloatingDateTime uses) // jsDateToFloatingDateTime uses) That's the real bug that needs to be fixed, I think.
Attachment #208709 -
Flags: first-review?(dmose) → first-review-
Comment 5•17 years ago
|
||
Comment on attachment 208709 [details] [diff] [review] patch v1 OK, I understand the complications in doing the right thing now. Can you be sure to file a bug about moving getDefaultTimezone to a service if there isn't one already? Thanks!
Attachment #208709 -
Flags: first-review- → first-review+
Assignee | ||
Comment 6•17 years ago
|
||
patch checked in
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•