RE: Alarm API Feedback

Giri wrote:
> 	e) Section 4.2:  DST guidance is not apparent in the current spec.  Is
> DST always honored with respect to alarms?  I'm unclear as to what should
> occur if a DST event (e.g. moving the clock forward or backwards by an hour)
> occurs between when the alarm was set and when the alarm occurs.

Christophe wrote:
> Yes, DST needs to be honored with respect to alarms or I believe this would
> lead to unexpected behavior for the user. I don't think it technically matters if
> there is DST event between the time the alarm is added and the time the alarm
> should fire. What is important is to consider the daylight savings in effect for
> the timezone* on the date that the alarm should fire. If the alarm is set for 6am,
> we need to fire the alarm at 6am on the given firing date considering the
> daylight savings in effect on that date for the timezone*.
> 
> *Which timezone is considered for daylight savings depends on the
> respectTimezone argument of the add() method (see example below).
> 
> Let's consider examples:
> - add(new Date(2013, 0, 16, 6, 0, 0), "ignoreTimezone"); // E.g. Wake up alarm
> clock on January 16, 2013 at 6am.
> This should wake you up at 6am on January 16th, 2013 in whatever timezone A
> you happen to be in on that day, considering the daylight savings in effect on
> that date for the timezone A.

Let's consider add(new Date(2013, 10, 3, 1, 10, 20), "ignoreTimezone"); // What happens when I set an alarm for Sunday, November 3 at 1:10:20.0am (in North America, outside Ohio)?

I haven't read your text, sorry. But having had to deal w/ headaches from timezones in the past, these things should be identified in the spec and included in test cases to ensure reasonable and interoperable behavior.

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

Received on Wednesday, 16 January 2013 20:58:04 UTC