KEP2: Modification of datetime type, introduction of 'tz' sub-tag (wiki revision 10645 of 2010-11-19)

Joon Radley joon at radleys.co.za
Thu Dec 16 13:18:15 CET 2010


> I expected the usual procedure here when calculating local times to UTC: To 
> use either the DST or the standard offset whichever is currently active.
> Why should this be done differently here?

You got it. Store date time in UTC and make your calculation based on the view of the user.

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 16 Dec 2010, at 11:30 AM, Hendrik Helwich wrote:

> Hi Georg,
> 
> Am Mittwoch, 15. Dezember 2010 19:42:20 schrieb Georg C. F. Greve:
>> On Tuesday 14 December 2010 11.03:23 Hendrik Helwich wrote:
>>> Also i am not sure if i understand the 4th bullet point:
>>> "All such timestamps MUST be calculated against *Standard Time*, NOT in
>>> Daylight Saving Time (DST). "
>> 
>> This is to avoid ambiguity.
>> 
>> Because the UTC time is calculated from the local time before storing it,
>> doing this against standard time or DST would yield different UTC results.
> 
> I expected the usual procedure here when calculating local times to UTC: To 
> use either the DST or the standard offset whichever is currently active.
> Why should this be done differently here?
> 
>> As we do not store whether or not this has been calculated from standard or
>> DST (and neither do I think we should) we need to fix the reference point.
> 
> Yes this should not be stored. But you know which offset must be taken because 
> of the rules which are stored in the time zone.
> With the proposed procedure incorrect UTC times will be stored if the DST is 
> currently active in the used time zone.
> 
> Maybe the proposed procedure in KEP 2 results from the datetimes like the 
> start date of an event that have the natural reference in a time zone which 
> is different to UTC.
> In this case it would be better to explicitly store this datetimes in a local 
> time (like it is done e.g. in iCalendar) because it is the natural modelling 
> and therefore less error-prone.
> 
> Best regards,
> 
> Hendrik
> 
>> Standard time seemed the obvious choice for a great variety of reasons,
>> including the question what regions would otherwise be doing that only have
>> standard time.
>> 
>> Best regards,
>> Georg
> 
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format




More information about the format mailing list