W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: [Alarm API] Time zone handling

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 9 May 2013 18:36:36 -0700
Message-ID: <CA+c2ei_1Z_1ZKipx88pycZmDDfwHZxToCbsrnquUjLn9ag68rQ@mail.gmail.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC