| Summary | shared calendars: users' timezones are not really respected |
| Queue | Kronolith |
| Queue Version | HEAD |
| Type | Enhancement |
| State | Accepted |
| Priority | 1. Low |
| Owners | |
| Requester | andrew (dot) nau (dot) ua (at) gmail (dot) com |
| Created | 01/03/2008 (129 days ago) |
| Due | |
| Updated | 01/04/2008 (128 days ago) |
| Assigned | |
| Resolved | |
| Attachments | |
| Milestone | |
| Patch |
> This is a known limitation of the current implementation, rather than
> a bug. I was sure we already had a ticket for this in the tracker,
> but obviously not.
> Times and dates are stored timezone dependent in the backend. This is
> legacy cruft from old Kronolith versions that didn't even have
> timezone support at all. With Kronolith 3 this is going to change,
> dates will be stored in UTC.
Jan,
Thanks, but this does not appear to work properly yet in 3.0-cvs. I have downloaded kronolith-HEAD-2008-01-04.tar.gz, installed it and found old behavior unchanged; the limitation is still there. Are there any release plans publicly available?
Priority ⇒ 1. Low
State ⇒ Accepted
Type ⇒ Enhancement
This is a known limitation of the current implementation, rather than a bug. I was sure we already had a ticket for this in the tracker, but obviously not.Times and dates are stored timezone dependent in the backend. This is legacy cruft from old Kronolith versions that didn't even have timezone support at all. With Kronolith 3 this is going to change, dates will be stored in UTC.
Queue ⇒ Kronolith
Summary ⇒ shared calendars: users' timezones are not really respected
Type ⇒ Bug
Priority ⇒ 2. Medium
State ⇒ Unconfirmed
i'm using horde-base-3.1.5 and horde-kronolith-2.1.6 from ports collection on freebsd. it seems i've found a bug in shared calendar feature: users' timezones are not really respected. suppose a user with timezone America/New_York creates a new event that lasts from 7am till 8am. when another user, whose timezone is Europe/Prague, looks at the calendar, he sees 7am-8am, which is not correct. It should be 1pm-2pm. timezone of the user who creates an event and timezone of the user who views an event must be respected.