W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2013

Re: [Alarm API] Time zone handling

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 9 May 2013 19:42:41 -0700
Message-ID: <CAAWBYDBigCxOf99pX+PFcGL0rofcbSQk740=oDHrii51QqvzhA@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Norbert Lindenberg <w3@norbertlindenberg.com>, Robin Berjon <robin@w3.org>, public-sysapps <public-sysapps@w3.org>, Marcos Caceres <w3c@marcosc.com>, public-script-coord <public-script-coord@w3.org>
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

Received on Friday, 10 May 2013 02:43:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:13 UTC