- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 9 May 2013 19:42:41 -0700
- 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 non-trivial. ~TJ
Received on Friday, 10 May 2013 02:43:28 UTC