[sync] contact dates of birth are time-shifted by one day to the past when syncing from horde to mobile

[Simon Brereton]

On 6 Apr 2013 17:37, "Michael J Rubinsky" <mrubinsk at horde.org> wrote:
>
>
> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>
>> Quoting Simon Brereton <simon.buongiorno at gmail.com>:
>>
>>> On 6 Apr 2013 15:38, "Michael J Rubinsky" <mrubinsk at horde.org> wrote:
>>>>
>>>>
>>>>
>>>> Quoting "lists.horde.org at pqaudio.de" <lists.horde.org at pqaudio.de>:
>>>>
>>>>> Am 05.04.2013 21:51, schrieb Michael J Rubinsky:
>>>>>>
>>>>>>
>>>>>> ..because the protocol *requires* all datetime fields to be
>>>>>> transmitted as UTC and the phone converts back to whatever timezone
>>>>>> the phone is set to use. The issue is with the protocol (or more
>>>>>> accurately, how 99% of clients interpret the protocol) - birthdays
>>>>>> occupy the entire day but the protocol is expected to transmit a full
>>>>>> datetime. This would be fine if both the client and the server would
>>>>>> agree on a specific time of day to always transmit a birthday e.g.,
>>>>>> 12:00 UTC... but they don't so what works for one client, in one
>>>>>> timezone, could be broken for the rest of the world.
>>>>>
>>>>>
>>>>>
>>>>> Thanks again Mike. That clears up a few of my questions.
>>>>> But I need to get more into it, because i am still wondering why its
>>>>> working fine with calendar events but not birthdays.
>>>>> Thank you for your time.
>>>>
>>>>
>>>>
>>>> It works for calendar events because they begin and end at a discreet
>>>
>>> time. Even "full day" events in the calendar have a defined start and
end
>>> time - as well as a flag for indicating to the client that it's a full
day
>>> event. Birthdays, on the other hand, have neither. This is way it's a
>>> problem that the protocol requires that the birthday be a full UTC
datetime
>>> field (containing both the date and the time component) while it doesn't
>>> specify what specific time birthdays should set the time component to.
>>>
>>> Can the application not simply make the decision to put 00:00:00?
>>
>>
>> Yes. That's exactly what we do...and the cause of the problem. Since
it's UTC, the client adjusts to the local/configured timezone. Depending on
the timezone, the can cause the birthday to be shifted to a different
calendar day.
>
>
> I should also mention that this is further complicated by the fact that
different clients treat birthdays differently. E.g., some Android clients
will *transmit* birthdays as occuring at 06:00:00 UTC, some other Android
clients treat the field as a text field. Yet others treat it as-is and
simply display the date without first converting it, while others treat it
as a true activesync datetime field.
>
> The bottom line is any logic done on the server (such as first
translating the birthday to 00:00:00 local time before converting to UTC)
to transmit a birthday "correctly" on a particular device can break the
birthday display on other devices and, possibly even cause the birthday of
any contact that has been edited on the device to be corrupted on the
server.
>
> IMO, this is a flaw in the protocol. The birthday field should either be
a straight text field, actual event object attached to the contact object,
or a specific time should have been defined for birthdays in the protocol
specs.

I don't disagree with you :)  thanks for the explanation.

Simon