- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 9 May 2013 18:36:36 -0700
- To: Norbert Lindenberg <w3@norbertlindenberg.com>
- Cc: public-sysapps <public-sysapps@w3.org>, Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
On Thu, May 9, 2013 at 3:50 PM, Norbert Lindenberg <w3@norbertlindenberg.com> wrote: > > On May 10, 2013, at 7:23 , Jonas Sicking wrote: > >> On Wed, May 8, 2013 at 6:15 PM, Norbert Lindenberg >> <w3@norbertlindenberg.com> wrote: >>> 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]. >> >> This isn't however accurate. The API does actually meaningfully work >> right now, it's just not described well as discussed above. The >> easiest way to describe how it works is through examples. There are a >> couple here: >> >> http://www.w3.org/2012/sysapps/web-alarms/#crossing-timezone-boundaries > > How is the first example supposed to work? The Date object constructed has time value 1358780400000, which corresponds to 7:00 PST, but 10:00 EST. How does the implementation of the API know it should fire the alarm at time 1358769600000? When the user changes timezone, the API adjusts the time of all scheduled alarms that were created using "ignoreTimezone" by adding or subtracting the appropriate value depending on how big of a timezone change was made. To put it another way, the API knows what timezone the user is in when the alarm is created, and knows any time the user changes timezone. / Jonas
Received on Friday, 10 May 2013 01:37:33 UTC