[Tickets #12200] Re: ActiveSync: Fix broken timezone on "due by" and "delayed start" fields

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12200
------------------------------------------------------------------------------
  Ticket             | 12200
  Updated By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | ActiveSync: Fix broken timezone on "due by" and
                     | "delayed start" fields
  Queue              | Nag
  Version            | Git master
  Type               | Bug
  State              | Feedback
  Priority           | 1. Low
  Milestone          |
  Patch              | 1
  Owners             | Michael Rubinsky
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-04-19 16:00) wrote:

> Can you explain the symptoms on the device that this was causing?  
> When I wrote this I was confused by the two fields because of how  
> all dates transmitted to the client must be in UTC anyway, and none  
> of the clients I have that support tasks seem to behave any  
> differently with those different values.

Here's an example from the WP8 phone using the fixed code:

---------------------
2013-04-19T17:56:17+02:00 DEBUG: [13545] I       <POOMTASKS:DueDate>
2013-04-19T17:56:17+02:00 DEBUG: [13545] I         2013-04-28T00:00:00.000Z
2013-04-19T17:56:17+02:00 DEBUG: [13545] I        </POOMTASKS:DueDate>
2013-04-19T17:56:17+02:00 DEBUG: [13545] I       <POOMTASKS:UtcDueDate>
2013-04-19T17:56:17+02:00 DEBUG: [13545] I         2013-04-27T22:00:00.000Z
2013-04-19T17:56:17+02:00 DEBUG: [13545] I        </POOMTASKS:UtcDueDate>
---------------------

The "DueDate" and "UtcDueDate" sent by horde without the fix were  
exactly the same values. On all tested phones this caused the due date  
to be off by two hours for my timezone, so the due date jumped to the  
previous day.

I _think_ (I haven't read the spec) that "DueDate" is in the current  
timezone, otherwise it would not make sense to have the additional  
"UtcDueDate" field.