[kronolith] Re: [horde] kronolith: adjusting for user vs. system time zone

[Mark Bennett]

I terms of a more comprehensive solution, my opinion is that storing dates in
UTC on the backend would simplify things in the long run. It seems like the
conversion to and from UTC would best take place in the actual back-end 
drivers
so that the rest of Kronolith can just not worry about it (though maybe that's
to simplistic thinking on my part). When a user creates an alarm that is part
of a shared calendar maybe have a checkbox that let's them indicate to
Kronolith that it should use "absolute time" -- meaning the alarm would 
trigger
at the same time for everyone regardless of their local time zone?

--Mark

Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Mark Bennett <bennettm+horde at mailsnare.net>:
>
>> Unless I?m missing something (which is entirely possible), it 
>> appears that the
>> kronolith alarms assume that the user?s time zone preference is the same as
>> the system clock. For example, we run all of our systems in UTC but 
>> most users
>> will set their preference to their local time zone. As a result, events that
>> should be generating reminders do not because kronolith is comparing 
>> everything against the system time.
>
> Yeah. See http://bugs.horde.org/ticket/?id=1088
>
>> One solution that we?ve been experimenting with is a patch to
>> lib/Kronolith.php that converst the system time to the user?s local time
>> before calling the $kronolith->listAlarms. That allows an apple-to-apple
>> comparison when looking for events that need to trigger a reminder.
>>
>> The kronolith storage drivers (at least the sql one) is pulling in possible
>> events from the current day to the current date + 1. Depending on the user?s
>> time zone, the system date could be a day ahead or a day behind the user, so
>> you really need to look at day-1 to day+1.
>>
>> I?ve roughed-in some code changes in our test environment to test this
>> approach and it seems to work well enough but wanted to get some feedback
>> before I offered up a patch. I?m sure there might be a more elegant approach
>> or maybe some other code dependency.
>
> This is something that ought to be solved in general, not just for
> alarms; there
> are questions about what should happen when users change their time 
> zone, etc.
>
> It has been suggested before that we should store all times as UTC in the
> backend and convert from there. The complication with that is that there are
> some events that always happen at 9am for whatever timezone you're in,
> and some
> that should change - perhaps giving events an optional timezone field would
> solve that? And of course some pretty robust conversion scripts, 
> probably with
> an option to either give events the server's timezone or the user's, would be
> needed.
>
> This should probably move to the kronolith list, btw, which I've cc'ed
> - please
> direct future posts there, and drop the horde list from replies.
>
> -chuck
>
> -- "But she goes not abroad in search of monsters to destroy." - John
> Quincy Adams
> -- Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: horde-unsubscribe at lists.horde.org