Closed Bug 321913 Opened 14 years ago Closed 14 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, major)

x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: spam1, Assigned: jminta)

References

Details

Attachments

(1 file)

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
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)
Attached patch patch v1Splinter Review
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.
Assignee: base → jminta
Status: NEW → ASSIGNED
Attachment #208709 - Flags: first-review?(dmose)
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 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+
patch checked in
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.