Re: Alarm API: ignoreTimezone/respectTimezone

Hi Christophe,
As Editor, we would like your opinion on the proposal below… if you agree, we can start sending pull requests to update the spec.


On Wednesday, May 15, 2013 at 5:44 PM, Mounir Lamouri wrote:

> Hi,
>  
> Marcos Caceres, Anne van Kesteren and I brainstormed some ideas
> regarding how to solve the ignoreTimezone/respectTimezone confusion.
>  
> To give some background, an Alarm is created from a Date object but when
> we create an Alarm we might want to set it at an absolute time. The
> common use case is an alarm clock set up to run every morning at 10:00.
> If the user's timezone changes to daylight saving or if the user moves
> to another timezone, this Alarm should still fire at 10:00.
>  
> The opposite use case is for an application that wants to schedule an
> event, for example a meeting. If the meeting is at "8th of January 2013,
> 12:00:00 CET", moving to PST shouldn't change the time when this event
> starts. In PST, the date would be "8th of January 2013, 3:00:00 PST".
> That means that the Alarm will now fire at 3:00 for the user locale
> timezone instead of 12:00.
>  
> "ignoreTimezone" and "respectTimezone" was used as a way to force
> developers to think about what value they pass but they are pretty hard
> to understand and it is quite easy to think that "ignoreTimezone"
> actually has the behaviour of "respectTimezone".
>  
> The solution we have been thinking of is to use a ScheduleTask object
> (aka Alarm) that can be constructed (contrary to Alarm). The WebIDL
> would look like:
> [Constructor (Date date, DOMString timezone, any data]
> interface ScheduledTask {
> readonly attribute DOMString id;
> readonly attribute Date date;
> readonly attribute DOMString timezone;
> readonly attribute any data;
> };
>  
> In the constructor, timezone will have to be a valid timezone identifier
> [1][2] or "current" or "none".
>  
> "current" would take the timezone of the passed Date object.
> "none" would not bound the Task to any timezone (equivalent to
> "ignoreTimezone").
>  
> Passing the empty string would not be allowed so, as for
> "respectTimezone"/"ignoreTimezone", we should get sure developers think
> at least 2 seconds of what they want to pass.
>  
> A nice side effect of that change is that applications will have an easy
> time to set a Task for another timezone than the user's timezone by
> using the timezone attribute. While, with the current API, they would
> have to do the time conversion themselves.
>  
> Another side effect of that proposal is that ScheduledTask has to be
> constructed instead of being returned by the add() method. This is
> mostly because working with objects seems nicer to me and others are
> likely to disagree ;). Though, some possibilities that are being enabled
> by that is to do:
> var t = [];
> t.push(new ScheduledTask(new Date() + delay, "current", {}));
> t.push(new ScheduledTask(new Date() + delay, "none", {});
> taskScheduler.add(t);
> (IOW, it allows getting an array of ScheduledTasks in add().)
>  
> This said, having a constructor for ScheduledTask would change a bit the
> id behaviour and every construction should generate a uuid that would be
> used when saving the object into the database. The backend would no
> longer return an id matching it needs. I do not think this is terrible
> but some might disagree.
>  
> I do not think that this email is solving the issues we have with
> timezones but I would like to kickoff the discussion based on a proposal
> and see if we can improve things from there.
>  
> For information, we had other ideas like having two different object:
> ScheduledEvent and ScheduledAlarm that would have a different timezone
> behaviour. Basically, instead of having to pick "respectTimezone" or
> "ignoreTimezone", developers would have to pick the object they prefer
> to use. It might just move the problem a bit without solving much.
>  
> Another path could be to ask the developer if the task should be updated
> when there is a timezone change. However, we might end up with confusion
> regarding what "updates" mean. Does updating means that the event at
> "8th of January 2013, 12:00:00 CET" will switch to "8th of January 2013,
> 12:00:00 PST" or to "8th of January 2013, 3:00:00 PST". We could also
> call a Task "relative" or "absolute". But again, it's not clear if that
> would be more understandable.
>  
> Comments are more than welcome! :)
>  
> [1] http://www.w3.org/TR/timezone/
> [2] http://www.w3.org/TR/2005/NOTE-timezone-20051013/
>  
> Thanks,
> --
> Mounir

Received on Monday, 3 June 2013 10:38:11 UTC