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

[Michael J Rubinsky]

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.
-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-keys
Size: 2200 bytes
Desc: PGP Public Key
URL: <http://lists.horde.org/archives/sync/attachments/20130406/13adcd4d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6062 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/sync/attachments/20130406/13adcd4d/attachment-0001.bin>