[kronolith] ActiveSync editing bug

[Simon Brereton]

On 19 February 2013 00:35, Jens-U. Mozdzen <jmozdzen at nde.ag> wrote:
> Hi Simon,
>
> Zitat von Simon Brereton <simon.buongiorno at gmail.com>:
>>
>> Hi
>>
>> I think this was raised once before and I thought it was going to be
>> fixed.  I don't know if it was, or not, or maybe it's me and my
>> set-up.
>>
>> Test
>> Create an all day appointment (in any time-zone) in Kronolith - say a
>> birthday or some such.
>> This will sync with an ActiveSync device
>> Use the ActiveSync device to edit the appointment for any reason
>> including changing the day, or the timezone, or the alarm.  (However,
>> more often than not it's because the appointments arrives as a solid
>> 24-hr block in my client's calendar than as the thin all day
>> notification.
>> Expectation is that the edits will accurately reflect the
>> appointment's new conditions.
>>
>> Reality is that a day is added to the appointment and the edits show.
>> And this addition occurs every subsequent edit.
>>
>> So, if I create an all-day appointment, edit it on the phone (usually
>> an Android), then a day is added and the appointment is now a 48 hour
>> block appointment instead of an all-day appointment.  Edit it again to
>> correct that and it's a 72 hour block appointment.
>>
>> In principle this means I can only ever use the web-interface for
>> editing my appointments (I have a lot of all day appointments
>> reflecting staff scheduling.
>
>
> while I reported this for e-mail invitations, it might be the same common
> cause (Horde sees the end date as inclusive, e-mail invitations and probably
> Android, too, sees it as exclusive date) -
> http://bugs.horde.org/ticket/11976

I think you might be right - because when I look on the device the
"all-day" appointment is now from Sun 00:00 to Mon 00:00 and at that
point changing it to an all-day appointment on the device is what
seems to cause it to add the extra day.  Rinse and repeat.

>> The second issue is that the alarm is 6 hours off.  The server is set
>> to UTC.  Horde5/Kronolith6 has a clean database which has always been
>> UTC.  If the appointment is in GMT-5 and the alarm is set for 5
>> minutes, it will go off 6 hours and 5 minutes before it's due if I'm
>> on the east coast, and ditto if the appointment is GMT+1.
>>
>> What can I do to diagnose this?
>
>
> I've had a situation that sounds like what you describe - the time zone in
> php.ini was set to UTC and when the user preferences are set to "Standard",
> then they use that PHP standard time zone. If a user then sets its time zone
> to the actual local time zone, this seem to have an offset.
>
> It's crucial (and correct, not "a bug") that all users have the proper time
> zone setting - either "Standard" (and php.ini does define the local time
> zone, rather than UTC) or by explicitly specifying the user's local time
> zone.

At least for my user the time-zone is explicitly set to GMT-5.  I'll
have to dig around and see what is in the php.ini (but it would
surprise me because the server is set to UTC specifically to avoid
issues like this).


Simon