Re: [Alarm API] Time zone handling

On Thu, May 9, 2013 at 7:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, May 9, 2013 at 6:42 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, May 9, 2013 at 3:42 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> 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.
>
> I said the second collapses into the first - both of them are set to a
> *particular* time zone, and don't change.  I strongly agree that the
> third case is distinct and important, because the logic required is
> non-trivial.

Ah, I misparsed your earlier email.

Yes. This is exactly what the API is trying to do. It relies on the
application logic and "respectTimezone" to implement the first two use
cases, and "ignoreTimezone" and "new Date(...)" to implement the last
use case.

We figured there are JS libraries out there that will help people
write the application logic for the second use case.

/ Jonas

Received on Friday, 10 May 2013 03:42:03 UTC