Re: [Alarm API] Time zone handling

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?

Norbert

Received on Friday, 10 May 2013 02:08:59 UTC