[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