Basic rationale of the KEP #2 design

[Jeroen van Meeuwen (Kolab Systems)]

Georg C. F. Greve wrote:
> Dear Jeroen,
> 
> While I think your points on RFC3339 are valid, as stated before, Hendrik
> has a point when it comes to local time storage.
> 

Very much true indeed; I wanted to emphasize where the (strong) recommendation 
for RFC 3339 came from.

Now that Kolab XML seems to be geared towards storing the local time, despite 
objections, requiring the ability to parse anything to RFC 3339 specifications 
does validate the points raised by Hendrik and others, and it has been part of 
my argument against storing the local time as well.

> On Monday 14 March 2011 23.04:51 Jeroen van Meeuwen (Kolab Systems) wrote:
> > You stated there is no way to restore the originally intended local time
> > when  UTC datetimes are used, but it seems the last-modification datetime
> > has been overlooked.
> 
> No, because the last-modification contains only the last modification date.
> 

The information that can be derived from a last modification datetime stamp 
includes whether the client had been subject to the dynamic DST offset or not, 
at the time of writing, only short of the timezone the client had been in 
during the write operation, a problem being solved by a solution provided 
elsewhere in the KEP, the 'tz' attribute. Regardless, it is moot in light of 
the other parser logic suggested.

> It is therefore not a source of information for whether the client that
> wrote the initial target time for the appointment assumed that that
> particular future time would be within DST or not.
> 
> The last-modification date only speaks about the current time, and may not
> even have been written by the client initially writing the appointment, as
> another client may have modified the event subsequently (e.g. the
> participants, or exceptions to recurrence).
> 

The argument on whether or not the ability to foretell the future is a client 
capability is completely moot with a UTC timestamp, as long as the operations 
to be executed against it are specified; write out something UTC only negating 
the baseline UTC offset, now everyone knows what they are reading.

You store something that never changes, you interpret it according to the 
specification of the format, and only then present it to the user.

If this user in South Africa, with the 11am Zurich conference call browses 
through his agenda;

- In the Zurich definition of a winter (e.g. non-DST), the event is supposed 
to be *presented* at 12am on his screen,

- In the Zurich definition of a summer (e.g. DST), the event is supposed to be 
*presented* at 11am on his screen.

> > You stated clients cannot foretell the future, but back in those days of
> > the  discussion, where the 'tz' attribute was only supposed to indicate
> > the authoritative timezone that should be used, a timestamp for 18:00 UTC
> > with a 'tz' attribute set to Europe/Berlin had been consistently saying
> > the same thing at the data storage level
> 
> It may look the same at a storage level, but may represent both
> 
> 	19:00 in Europe/Berlin
> 	20:00 in Europe/Berlin
> 
> in a user's intention.

Without any prescribed parser logic, such as could, arguably, be considered to 
be the case with humans, sure. It's therefor significantly less relevant in 
writing a specification for a parser, mind you.

To put some anology on it, I could throw out a bunch of data that makes 
perfect sense to a library built to certain specifications, but while humans 
cannot just read and interpret it, is argued -by humans- to be ambiguous.

> > A very simple fix would have been to specify clients must
> > write out the datetime as if DST was never invented, and only use their
> > baseline offset; two situations for writing the data out exist:
>
> I also thought at some point this might resolve the situation, and I
> believe there even was a version of the KEP that attempted it.
> 
> The problem is that it irrevocably falsifies the entries.
> 

Define "falsifies" bearing in mind the format is supposed to be parsed (by a 
machine) using a specification, not humans.

> 10:00 in Berlin in the summer is 08:00 UTC, not 09:00 UTC, as would be
> written out if following the logic proposed above. Comparisons of entries
> based on UTC would therefore become impossible, because one would
> necessarily have to first translate into local time, and back into "real
> UTC" to know how they actually relate to each other.
> 
> Such storage, while also being RFC3339 incompliant because it does not
> actually map to UTC directly, does not seem an improvement over storing
> local time directly.
> 

Please read section 4.3 of the RFC.

With regards to the aforementioned (let's strip the offset off of the local 
time to make it easier to parse), please read section 4.4 of the RFC.

> For some other entries, e.g. last-modified, such a falsification of the
> datetime field would likely throw off a substantial number of clients
> which are unlikely to care for the time zone of this field, and just want
> to use it to sort through entries by order of last modification, for
> instance.
> 

Sorting UTC timestamps is a lot easier then sorting local times with offsets, 
FWIW, unless of course you first translate the local times (ignoring the 
offsets as per specification), using the 'tz' attribute... back to UTC.

I would further like to emphasize, and strongly recommend, that the 'tz' 
attribute is introduced only as an attributes to those datettime tags that 
have a use for it; recurring events.

Kind regards,

Jeroen van Meeuwen

-- 
Senior Engineer, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
t: +316 42 801 403
w: http://www.kolabsys.com

pgp: 9342 BF08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kolab.org/pipermail/format/attachments/20110315/550cd265/attachment.html>