Re: [Alarm API] Time zone handling

On Thu, May 9, 2013 at 7:08 PM, Norbert Lindenberg
<w3@norbertlindenberg.com> wrote:
>
> On May 10, 2013, at 10:36 , Jonas Sicking wrote:
>
>> 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.
>
> I think you'll have to be more specific about how this adjustment works in order to avoid random differences between implementations. A more interesting case than traveling within the US in January would be traveling between the US and the EU around the time when one of them switches to daylight saving time or back. E.g., a user in California on October 15, 2013 sets an alarm for October 29, 2013, 9am, using "ignoreTimezone", then travels to Portugal on October 22, 2013, when both the US and the EU are still in DST. How do you ensure that the alarm goes off on October 29, 2013, 9am Western European Standard Time, which is no longer in DST?

The simplest way I guess would be to do something like:

When the alarm is created:
1. Convert the passed in Date object to the array [2013, 9, 29, 9, 0, 0, 0]
2. Store this array along with other meta information about the alarm
3. Schedule a OS-level alarm for the timestamp represented by the
passed in Date object

When the timezone is changed
1. Read previously saved meta information.
2. Create a new Date object using |new Date(2013, 9, 29, 9, 0, 0, 0)|
3. Remove previously scheduled OS-level alarm.
4. Schedule a OS-level alarm for the timestamp represented by the Date
object from step 2

There indeed doesn't seem to be a way to simply add/remove a constant
number of microseconds to all saved alarms when there's a timezone
switch. The amount of time it needs to be adjusted depends on the
scheduled time and the DST rules for the two zones that the alarm was
created in and that the user is currently in.

/ Jonas

Received on Friday, 10 May 2013 03:17:07 UTC