321913 - alarm service's mRangeEnd needs to be more timezone sensitive (causes alarms not to fire in some timezones, like GMT+8)

Status: RESOLVED FIXED

(Calendar :: Internal Components, defect)

Description

[LaurentS]

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.

Comment 1

[LaurentS]

I am located in China/Shanghai (GMT+8) which might help in understanding the timezone issue.

Comment 2

[Joey Minta]

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.

Comment 3

[Joey Minta]

Attachment: patch v1

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

[Dan Mosedale (:dmosedale, :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.

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

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!

Comment 6

[Joey Minta]

patch checked in