RE: Alarm API: ignoreTimezone/respectTimezone

Hi,

Very sorry for the delay.

I am in favor of adding a timezone attribute to the ScheduledTask interface. Storing the timezone separately from the EcmaScript Date is also how timezones were handled in Tizen.

However, there are several things in the proposal that do not seem strictly related and that I'm not sure we want:
1. Why does ScheduledTask need to have a constructor? Why cannot we simply pass the timezone to the TaskManager.add() method? This would be a less intrusive change and still keep the same functionality unless I'm missing something.
2. Why did the data argument become mandatory? It is currently optional as I think it should be.

On a side note, I feel that using "currentTimezone" / "noTimezone" instead of "current" / "none" may lead to slightly more readable code.

Kr,
Christophe DUMEZ.
________________________________________
From: Mounir Lamouri [mounir@lamouri.fr]
Sent: Wednesday, May 15, 2013 19:44
To: public-sysapps@w3.org
Subject: Alarm API: ignoreTimezone/respectTimezone

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:55:01 UTC