[Alarm API] Time zone handling

The time zone behavior in the spec seems to be based on a misunderstanding of how JavaScript handles time zones. In particular, there's a reference to "the timezone information of that [ECMASCRIPT] Date object".

ECMAScript Date objects don't have time zone information. After construction, all a Date object has is a time value, the number of "milliseconds since 01 January, 1970 UTC" [1]. Time zone information is used in the constructor to calculate the new object's time value if the "year, month [, date [, hours [, minutes [, seconds [, ms ] ] ] ] ]" form of the constructor is used [2] and [3], or if a string is provided to the constructor for parsing [4] and [5]. No time zone information is used if a single non-String value is provided to the constructor [4]. Date objects represent incremental time [6].

In an API that's designed around a Date instance, time zone directives "respectTimezone" or "ignoreTimezone" are therefore meaningless. If the API is intended to interpret time zones (I don't know whether it is), it needs a different data type to represent field based time with time zone information [7].

Using just Date instances, it's easy to handle use cases that involve individual events with a fixed point in time, such as
- Wake me up 7 hours from now.
- Remind me of a one-time meeting scheduled in my current time zone, even if I move to a different time zone before the meeting.
- Remind me of a one-time meeting scheduled in UTC, no matter where I am.
- Remind me of a one-time meeting scheduled in Central European Time, no matter where I am, as long as the application knows how to convert from Central European Time to UTC before calling the API.

An API using just Date instances cannot handle use cases such as:
- Wake me up tomorrow at 7:00 local time in a time zone I'm traveling to, but which I haven't told my device about yet.
- Wake me up at 7:00 local time every day, no matter where I am.
- Remind me each time of a recurring meeting scheduled in my local time zone, with correct handling of DST or time zone offset changes.

"Working with Time Zones" has more information on use cases and possible solutions [8].

[1] http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.1
[2] http://ecma-international.org/ecma-262/5.1/#sec-15.9.3.1
[3] http://ecma-international.org/ecma-262/5.1/#sec-15.9.1.9
[4] http://ecma-international.org/ecma-262/5.1/#sec-15.9.3.2
[5] http://ecma-international.org/ecma-262/5.1/#sec-15.9.4.2
[6] http://www.w3.org/TR/timezone/#incremental
[7] http://www.w3.org/TR/timezone/#fieldbased
[8] http://www.w3.org/TR/timezone/

Norbert


On May 9, 2013, at 2:54 , Marcos Caceres wrote:

> Hi,  
> The SysApps WG would appreciate if the JS folks could take a look at:
> http://web-alarms.sysapps.org/
> (it's nice and small, promise)
> 
> 
> And provide us some feedback on the idiomatic aspects (i.e., to make sure it isn't "another crap W3C API"™).  
> 
> A disclaimer: The API's name is terrible, we know that (should be called Web Cron or Web Scheduled Tasks or something less awful). We've tried to use Futures, but we are new to them.  
> 
> Anyway, any/all, comments welcome.  If you want to file bugs directly (or see what bugs we have open):
> https://github.com/sysapps/web-alarms/issues/ (https://github.com/sysapps/web-alarms/issues/new)
> 
> Kind regards,
> Marcos

Received on Thursday, 9 May 2013 01:22:28 UTC