[kronolith] ActiveSync editing bug

[Jens-U. Mozdzen]

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

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

Regards,
Jens