Recurring events with timezone

Hendrik Helwich h.helwich at tarent.de
Wed Oct 20 13:34:43 CEST 2010


Am 20.10.2010 10:30, schrieb Joon Radley:
> Hi Hendrik,
>
>    
>> If i am in Johannesburg my Kontact can convert each start-time to the UTC time by using the stored time zone from germany and then convert it to the system local time.
>> In october:
>> german local 10 ->  UTC 8 ->  south africa local 10
>> in november:
>> german local 10 ->  UTC 9 ->  south africa local 11
>>      
> Now lets turn this around, you create the event in Johannesburg and accordingly include the CAT time zone:
>
> How will you now do the conversion for the German user with only the Johannesburg Time Zone information?
>    

You mean if the meeting should happen in Johannesburg? Its just similar. 
Add the local timezone to the kolab xml:

<?xml version="1.0" encoding="UTF-8"?>
<event version="1.0">
<product-id>KOrganizer 3.5.9 (enterprise35 20100805.1161816), Kolab
resource</product-id>
<uid>libkcal-2077575338.372</uid>
<sensitivity>public</sensitivity>
<start-date>2010-10-19T10:00:00</start-date>
<summary>Test</summary>
<timezone>
	<id>Africa/Johannesburg</id>
	<standard-time name="SAST">
		<offset>+0200</offset>
	</standard-time>
</timezone>
<recurrence cycle="monthly" type="daynumber">
	<interval>1</interval>
	<daynumber>19</daynumber>
	<range type="none"></range>
</recurrence>
<end-date>2010-10-19T12:00:00</end-date>
</event>

Then the meeting start time would be always at 10 o'clock in Johannesburg.
If a person in germany would see this event it would be converted like this:

In october:
south africa 10 ->  UTC 8 ->  german local 10
in november:
south africa 10 ->  UTC 8 ->  german local 9


Greets,
Hendrik

>
> Best Regards
>
> Joon Radley
>
> Cell: +27 (0)83 368 8557
> Fax: +27 (0)86 547 2353
> E-mail: support at toltec.co.za
> Web: www.toltec.co.za
>
>
>
> On 20 Oct 2010, at 9:34 AM, Hendrik Helwich wrote:
>
>    
>> Am 20.10.2010 08:46, schrieb Joon Radley:
>>      
>>> Hi Hendrik,
>>>
>>> This is an excellent example. Your argument is that the incorrect conversion in the client of UTC ->   local time can be fixed by adding time zone information to the object.
>>>
>>> Lets run a use case with this. User A is the creator of the object and is situated in Johannesburg. User B that shares the folder is situated in Germany (for the daylight savings time).
>>>
>>> The problem is: UTC ->   User B local time is incorrect.
>>>
>>> Your suggested solution is: User A Time Zone + User A Local Time ->   UTC ->   User B local time
>>>
>>> UTC ->   User B local time conversion will still be broken, as you need User B TZ to fix the incorrect calculation. Thus by adding the User A TZ information to the object no problem is solved.
>>>
>>> The only time when the TZ information will help is when User A and User B is in the same time zone and they both know it. All other user cases do not benefit from User A’s TZ information.
>>>
>>> You are trying to fix a client “bug” by providing it with information, which will only be valid/helpful in very limited cases.
>>>
>>> By fixing the UTC->   locale conversion you will fix all the use cases. The localtime function has never failed me. Is there a problem with it on your OS?
>>>
>>>        
>> Hi Joon,
>>
>> timzones are working fine on my OS :-) the UTC time can surely be used for single events/tasks. But it is possible to code recurring events in kolab so you must add timezones to the format even if they are complex. This is obvious i think. Otherwise it is not possible to fix this problem.
>>
>> To the example:
>> The correct way would be to make the kolab xml with timezone e.g. like this:
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <event version="1.0">
>> <product-id>KOrganizer 3.5.9 (enterprise35 20100805.1161816), Kolab
>> resource</product-id>
>> <uid>libkcal-2077575338.372</uid>
>> <sensitivity>public</sensitivity>
>> <start-date>2010-10-19T10:00:00</start-date>
>> <summary>Test</summary>
>> <timezone>
>> 	<id>Europe/Berlin</id>
>> 	<standard-time name="CET">
>> 		<offset>+0100</offset>
>> 	</standard-time>
>> 	<daylight-saving-time name="CEST">
>> 		<offset>+0200</offset>
>> 		<start-date>
>> 			<month>march</month>
>> 			<day count="-1">sunday</day>
>> 		</start-date>
>> 		<end-date>
>> 			<month>october</month>
>> 			<day count="-1">sunday</day>
>> 		</end-date>
>> 	</daylight-saving-time>
>> </timezone>
>> <recurrence cycle="monthly" type="daynumber">
>> 	<interval>1</interval>
>> 	<daynumber>19</daynumber>
>> 	<range type="none"></range>
>> </recurrence>
>> <end-date>2010-10-19T12:00:00</end-date>
>> </event>
>>
>> (I added the timezone block and changed start-date and end-date to the local times)
>> My Kontact now can see that i am in the same time zone as it is stored in the event and does not need to convert the local times. It can show me the 10 o'clock start-time for all the year. It also can do the stored local ->  UTC ->  local conversion but this would be an identity function and will cause the same result.
>>
>> If i am in Johannesburg my Kontact can convert each start-time to the UTC time by using the stored time zone from germany and then convert it to the system local time.
>> In october:
>> german local 10 ->  UTC 8 ->  south africa local 10
>> in november:
>> german local 10 ->  UTC 9 ->  south africa local 11
>>
>> So this example could be calculated correctly. Without storing the time zone information of germany that could not be possible.
>>
>> Greetings
>>
>> Hendrik
>>
>>      
>>> [..]
>>>
>>>        
>> _______________________________________________
>> Kolab-format mailing list
>> Kolab-format at kolab.org
>> https://kolab.org/mailman/listinfo/kolab-format
>>      
>    
>
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20101020/d8d7d4f4/attachment.html>


More information about the format mailing list