KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
Georg C. F. Greve
greve at kolabsys.com
Wed Dec 1 18:15:05 CET 2010
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>
More information about the format
mailing list