Re: [Alarm API] Time zone handling

On Thu, May 9, 2013 at 8:16 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.

I should also say that if you have suggestions for how to make this
clearer in the spec, or suggestions for how to completely change this
API to make it easier to understand/use for authors, then I'm all
ears. That's exactly the purpose of the initial email to
public-script-coord.

This timezone stuff is really complicated. I believe we have have
really tried to optimize the API for authors rather than implementors,
but still the API is very hard to understand. So if you have
suggestions for how to improve it then that would be awesome.

/ Jonas

Received on Friday, 10 May 2013 03:45:08 UTC