[horde] Timeshift on ActiveSync to Horde

Michael J Rubinsky mrubinsk at horde.org
Fri Dec 16 01:06:47 UTC 2011


Quoting Michael J Rubinsky <mrubinsk at horde.org>:

> Quoting Stephan Kleber <stephan at admin.nabira.de>:
>
>> Zitat von Michael J Rubinsky <mrubinsk at horde.org>:
>>> That depends. If you don't use UTC then all events in Kronolith  
>>> are in a "floating" timezone. That is, they are always assumed to  
>>> be in the user's current timezone. This is fine if you never cross  
>>> timezones or do not have to schedule meetings with people in more  
>>> than one timezone, or have recurring events that span DST switches  
>>> etc... If you want to really support timezones, you need to use UTC.
>>>
>>> So, if the user's device is in a different timezone than their  
>>> Horde prefs indicate, this could very well be the source of your  
>>> issue.
>>
>> Until now I had no issues with timezones. All my users are in one  
>> TZ and none has ever asked about it or reported problems. I see the  
>> benefits of using UTC based storage, but if conversion is not  
>> mandatory, it should work this way either.
>>
>> I will convert the database all the while. Perhaps it helps,  
>> although I would not have the necessity to do it otherwise.
>>
>> Stephan
>
>
> I have not forgotten about this. In debugging *this* issue, I  
> discovered another, more important issue that caused a 1 hour  
> timeshift from server -> client for recurring events that span a DST  
> transition (as opposed to your reported issue of client -> server).  
> The fix for *this* issue is included in the latest round of releases  
> that dropped today (including the ActiveSync and Date package) and  
> had to due with a bug parsing a date object on the exact hour of a  
> DST transition.
>
> The issue you are reporting is due, I believe, to the fact that we  
> seem to be currently ignoring the timezone data structure that is  
> sent from the device. Part of the problem is that all of the devices  
> I've tested only send transition dates and offsets - and omit the  
> timezone identifier (this is allowed by the spec) - so we are going  
> to need to either parse these values into a timezone identifier, or  
> otherwise adjust the UTC time. This should only affected recurring  
> events that are created or edited on the device that span a DST  
> transition.
>
> It is most likely a coincidence that you noticed this after a recent  
> upgrade - it is more likely the recent switch from daylight to  
> standard time is what has brought this to your users' attention.


These issues should now be fixed in Git master. I'm not releasing  
another PEAR package at this time, because there were a good bit of  
changes made and I want some time for myself, and hopefully others, to  
test that things are working well first.


-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org



More information about the horde mailing list