UPDATE: KEP 2: Modification of datetime: store local time, add 'tz' attribute (revision #10743)

[Shawn Walker]

I thought I bump this response from Joon.  I have been involved in the development for the connector
for Outlook.  What Joon is saying is true about Outlook to some extent.  We don't do any calculation
regarding to DST/NON-DST that this time is in this or that timezone.  In Outlook recurrence data,
there are two types of times that we must handle on a recurring event since Outlook requires both
UTC and local times to a recurring event that contains exceptions.  An exception to a recurring
event would require us to set some of the times to local time and that may have us set the local
time to regards to DST/NON-DST when we convert a UTC time to local time for that exception.  But
other than that we just set the Outlook TimeZone Information and Outlook handle the rest of how to
display the recurring event.

The recurrence data that we create for Outlook is only used to how to display the recurring event in
Outlook's calendar view.  When a user open a recurring series or occurrence, Outlook will open the
message (a hidden message that is attached for exceptions) to extract the event and those times are
in UTC and local times also, but the start and end is always in UTC in Outlook.  So, again, Outlook
does all of the work of converting a time from UTC to Outlook's timezone (you can configure Outlook
to use a different timezone from what the windows' timezone been configured, but by default it will
set the timezone to windows' timezone).

Regards,
Shawn

On 12/26/2010 2:55 AM, Joon Radley wrote:
> Hi Andrew,
> 
>> Perhaps I have misunderstood, but you appear to be saying that the way
>> that Toltec uses Outlook means that it is not possible to schedule
>> recurring events correctly for a locale that uses DST.
> 
> Not in the way that KEP 2 requires.
> 
>> I don't think it is reasonable to criticise the proposal to say "but we
>> can't implement that because we depend on X" unless you can provide an
>> alternative approach which will also achieve the desired goal.
> 
> I would love to give an alternative approach, but at the moment it seems that the debate has reached infinite loop stage. KEP 2 is so far out of reach that I cannot even suggest an modification that will work.
> 
> This is what I would suggest.
> 1) All timestamps are stored in UTC in the RFC3999 Zulu format without micro seconds. (The current format).
> 2) Inclusion of a tz structure in event objects. 
> 2.a) NON-DST zone (Only gives offset from UTC)
> 2.b) DST Zone (gives rules for DST start/end with bias and time offsets. Can be one or more rules)
> 3) 2 contains a non fixed text representation of the zone name. This is just used for displaying information.
> 4) The tz tag must be a root tagged. This will ensure that the tag is always preserved.
> 5) Together with a tag and the format version number the storage format can indicate that tz field was used in calculating the the timestamps.
> 
> Note: the view of time zones and the calculations performed on the view is all done by Outlook and the connector developers cannot changes this. It can only be assumed that the different databases will have he same rules in 99.999% of the time.
> 
> 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 24 Dec 2010, at 7:51 AM, Andrew McMillan wrote:
> 
>> On Thu, 2010-12-23 at 14:19 +0200, Joon Radley wrote:
>>> Hi Georg,
>>>
>>>> What can/do you pass on to Outlook, and how is it treated?
>>>
>>> All time in Outlook is stored in UTC. Newer version has a field for
>>> time zone where they preserve the time zone from iCalendar requests,
>>> but from what I can see it is never used in calculations.
>>>
>>>> I'm wondering whether you aren't already doing what the KEP
>>> requests 
>>>> implicitly, because I didn't hear reports of events jumping one hour
>>> between 
>>>> standard and DST for Outlook with Toltec.
>>>
>>> This cannot be as we just use UTC and Outlook uses the locale
>>> information to calculate from and to UTC.
>>
>> Hi Joon,
>>
>> Perhaps I have misunderstood, but you appear to be saying that the way
>> that Toltec uses Outlook means that it is not possible to schedule
>> recurring events correctly for a locale that uses DST.
>>
>> Are there other ways to use Outlook which do make it possible to
>> schedule recurring events correctly for locales with DST?
>>
>> Should the proposal be reworded in some way which means you can use an
>> alternative approach which will work?
>>
>> I don't think it is reasonable to criticise the proposal to say "but we
>> can't implement that because we depend on X" unless you can provide an
>> alternative approach which will also achieve the desired goal.
>>
>> Regards,
>> 					Andrew McMillan.
>> -- 
>> ------------------------------------------------------------------------
>> http://andrew.mcmillan.net.nz/                     Porirua, New Zealand
>> Twitter: _karora                                  Phone: +64(272)DEBIAN
>> It is truth which you cannot contradict; you can without any difficulty
>>                      contradict Socrates. - Plato
>>
>> ------------------------------------------------------------------------
>>
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format

-- 
Shawn Walker
Senior Software Developer
swalker at bynari.net
Bynari, Inc.
222 W Las Colinas Blvd, Suite 1320N
Irving, TX  75039
http://www.bynari.net
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax