KEP 2: Modification of datetime type, introduction of 'tz' sub-tag

[Georg C. F. Greve]

Hi Hendrik,

On Wednesday 01 December 2010 13.00:27 Hendrik Helwich wrote:
> I am aware that a local offset from the UTC time zone is not a full time
> zone information but anyhow it is a partially timezone information in my
> opinion. 

It seems pointless to argue whether this is partial timezone information, 
especially when we know and agree it is a superfluous offset.

Because computers tend to be capable of performing whole integer subtraction 
and addition with ease and high reliability, I do not believe this is a major 
issue or complication, and it is already implemented on all systems.

So arguing over this is comparatively moot when every operating system already 
provides solid parsing capability for this format.

But what I *would* strongly argue is that we should *not* invent yet another 
format, especially one that looks dangerously close and confusingly similar to 
the established standard.

Also, as pointed out by others, geographic references are ultimately the only 
long-term reliable approach, as nothing short of a major tectonic shift is 
likely to change them substantially - and even then the database could adapt.


> This could be a good compromise i would say.

Alright. So I've worked that into the KEP. The draft has been updated at

	http://wiki.kolab.org/User:Greve/Drafts:KEP:2

This ensures full backward compatibility, provides clients with a very smooth 
transition period, and keeps the simplest possible notation. 


> The meeting will only be at the same local time for people which are in the
> same time zone like the event (or have the similar DST rules).

Yes. The situation will change if a group of people in Brazil agree to meet 
every Monday at 11:00 according to the time in London. If then Brazil or the 
UK change their DST rules, *and* the people do not update their systems, 
consequently running orphaned installations of Kolab, then one or more of them 
might miss one meeting.

But then they would also do that if they miss the bus in the morning, or have 
a cold. At some points scenarios get sufficiently esoteric to warrant being 
ignored. Plus them using orphaned not updated systems makes it likely it is 
going to be no-ones support problem.

If they complain on kolab-users at kolab.org that they ran into this case, I will 
be happy to let them know they should run "aptitude upgrade" or "yum update" 
at least once or twice a year to get their security and timezone database 
updates.


> Ok that could never be guaranteed you are right. But the kolab clients must
> anyway show the same time to the people i would say. With this argumentation
> we do not need to adapt the kolab format and add time zone at all.

I do not follow.

We have identified an issue for a specific scenario.

And we have identified a solution.

Because of the nature of the issue, we know we cannot solve this problem 100% 
right now no matter what we do, but we can reach 95% immediately, and one 
approach even allows us to reach 100% in the future.

So why not take the 95% solution now that allows us 100% later?


> But can we rely on that everyone does always update his system directly if
> updates are available?

They do not need to update immediately when updates become available.

They just need to update once between the time the database has changed, and 
the time when that change becomes relevant - which is typically quite some 
time into the future.

So there is at least a window of several months to update.

Anyone who is concerned enough to have a support contract is likely also 
concerned enough to ensure security updates are made.


> This would be great if the time zone database is always automatically
> synchronized with a central authority.
> But when will this be available? 
> And how long must we wait till we can rely
> on that the vast majority of systems are automatically up to date?

The mechanism already exists, it is "yum/aptitude" or "cron + ftp".

There is an authoritative location for FTP to get the current database, and 
distributions already ship it.

So it is about when the RFC will be finished and implemented. There is no 
guarantee for that, but the proposal seems to be backed by corporate 
interests, so I'd expect it to mature normally and services to become 
available within the next 3-5 years.

If in the meantime you are this concerned about the situation, you can of 
course provide client-side logic to track changes to the database and ensure 
that you calculate correctly for your users. That would still only be half the 
effort of the static + database approach, and would have none of the weaknesses 
associated with it.

Personally I think that is overkill, but it can be done.

Best regards,
Georg


-- 
Georg C. F. Greve
Chief Executive Officer

Kolab Systems AG
Zürich, Switzerland

e: greve at kolabsys.com
t: +41 78 904 43 33
w: http://kolabsys.com

pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 308 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20101201/3181d140/attachment.sig>