W3C home > Mailing lists > Public > public-sysapps@w3.org > June 2013

Re: Alarm API: ignoreTimezone/respectTimezone

From: Marcos Caceres <w3c@marcosc.com>
Date: Mon, 3 Jun 2013 11:37:39 +0100
To: Christophe Dumez - SISA <ch.dumez@partner.samsung.com>
Cc: "public-sysapps@w3.org" <public-sysapps@w3.org>
Message-ID: <31749248F060463599529C1460D0B41A@marcosc.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:36:13 UTC