Re: [Alarm API] Time zone handling

On Thu, May 9, 2013 at 3:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, May 9, 2013 at 3:37 PM, Norbert Lindenberg
> <w3@norbertlindenberg.com> wrote:
>> On May 9, 2013, at 22:01 , Robin Berjon wrote:
>>> On 09/05/2013 03:15 , Norbert Lindenberg wrote:
>>>> The time zone behavior in the spec seems to be based on a
>>>> misunderstanding of how JavaScript handles time zones. In particular,
>>>> there's a reference to "the timezone information of that [ECMASCRIPT]
>>>> Date object".
>>>
>>> Wasn't TC39 working on a TZ-aware variant of Date? I thought that there was something but I can't seem to dig it up. It would come in handy, and not just here.
>>
>> The TC39 internationalization ad hoc has recognized the need for better time zone support and is looking at proposals to provide API that lets callers specify the time zone used in constructing or interpreting Date objects, e.g. [1]. These proposals don't involve adding time zone information to the objects themselves. There has been a suggestion on es-discuss to do so, but this has found no support in the ad hoc [2].
>>
>> It would help if we had a list of use cases that the Alarm API has to address, with their requirements for time zone support. Does such a list exist?
>
> The basic use-cases appear to be:
>
> * specify an alarm according to my current timezone (activate my
> reminder app at 7PM tomorrow to meet someone for dinner)
> * specify an alarm according to a specific timezone (activate my VC
> app at 8am Tokyo time to attend the meeting)
> * specify an alarm relative to whatever the current timezone (activate
> my alarm at 7:30am each morning, no matter where I am in the world)
>
> The second collapses into the first if you're willing to do the tz
> adjustment yourself (/in app code).

It is certainly possible to always use "respectTimezone" or
"ignoreTimezone" and use application logic to implement the other.
That does require applications to be started and notified any time the
user changes timezone.

This isn't a big battery burden, since it's such a rare event. But
getting the logic right, and remembering to implement that logic, is
non-trivial.

FWIW, this is why we decided to not make the respectTimezone argument
optional. This is such a complex question that we wanted to force
authors to make an explicit choice.

/ Jonas

Received on Friday, 10 May 2013 01:43:55 UTC