[Tickets #14084] Free/busy view time zone doesn't match calendar time zone
noreply at bugs.horde.org
noreply at bugs.horde.org
Thu Aug 13 20:01:02 UTC 2015
DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.
Ticket URL: https://bugs.horde.org/ticket/14084
------------------------------------------------------------------------------
Ticket | 14084
Created By | rikus.goodell at cpanel.net
Summary | Free/busy view time zone doesn't match calendar time
| zone
Queue | Kronolith
Version | 4.2.9
Type | Bug
State | Unconfirmed
Priority | 2. Medium
Milestone |
Patch |
Owners |
------------------------------------------------------------------------------
rikus.goodell at cpanel.net (2015-08-13 20:01) wrote:
Description:
The Kronolith free/busy view sometimes disagrees with the calendar
view on which time zone to apply. This results in all of the "busy"
blocks for an invitee appearing shifted either left or right.
What we've found is that the getFreeBusy ajax response contains the
correct unix timestamps for the invitee's busy times, but the
front-end Javascript appears to be applying the wrong time zone when
converting them to human-readable format. This happens when the
browser time zone doesn't match the server time zone (or Horde's
configured time zone).
Steps to reproduce:
- Set your server clock to one time zone (e.g., Europe/Budapest).
- Set your desktop computer clock to another time zone (e.g.,
America/Chicago).
- Make sure you have left your Horde time zone on "Default" in the
Locale and Time preferences.
- As one Horde user, create an event in a Horde calendar at 22:00.
- As another Horde user, begin creating another event
- View the free/busy for the first user as an invitee for the new event
- Notice that the busy time has shifted hours earlier in the day in
the free/busy view, while it remains at the correct original time in
the calendar view
- Optional: Inspect the getFreeBusy ajax response, and notice that
the timestamps it provides are correct.
Possible fix:
It might help for the server to communicate a numeric hour offset back
to the client in the getFreeBusy response. That way the parts of the
UI that manipulate times and dates in Javascript will agree with the
parts where the manipulation has already occurred on the server.
More information about the bugs
mailing list