KEP 2: Modification of datetime type, introduction of 'tz' sub-tag
wrobel at kolabsys.com
Wed Dec 8 17:44:40 CET 2010
Zitat von Hendrik Helwich <h.helwich at tarent.de>:
> Hi Gunnar,
> Am Dienstag, 7. Dezember 2010 22:33:45 schrieb Gunnar Wrobel:
>> Still I can imagine that people might actually keep a system without
>> updates for years. "Never change a running system" is sensible after
>> *But* ... if this is causing problems then it can be easily fixed by
>> updating the problematic system. Static information on DST in the
>> format would mean that you could only fix the problem by trying to fix
>> problematic events in the Kolab IMAP storage. This is *way* harder and
>> nothing you want to go into.
> you are right, this would be complex and not very satisfying. But i still
> think it could be problematic to use timezone informations which is sperad in
> different databases on the diverse possible kolab client systems.
I'm not denying that. But I agree with Georg that the other
alternatives have a significantly higher potential for problems. And
the fact that the user or admins can fix the problem by updating a
machine seems quite okay to me.
> What do you think about adding a time zone database to the kolab server
> Kolab clients could get time zone informations from a central authority.
> Through this it could be assured that all clients have the same time zone
> data to calculate the shown times with. Also it could be assured that the
> time zone information for all clients is always up to date.
Yes, that would be great and I totally agree that this is the way to
go. In fact Georg already mentioned there is a RFC in the works that
should do for DST what NTP does for for time. This would be exactly
what you propose.
The important point here: It is outside of the scope of the Kolab
server. The Kolab server also does not care about NTP. Well, it could.
But there is a boundary where it stops making sense to care too much
about the details if there are established solutions to solve a
problem and these are handled by the system. Agreed: Concerning DST we
are not there yet but it looks like things are moving into the right
If you need absolutely reliable resource booking / event management it
is important that all your systems are in sync as much as possible.
And I consider it to be the job of the network admin(s) to ensure
that. Whether that means keeping Olson in sync on the clients or
installing an NTP-like DST-sync service later.
> Best regards,
> Kolab-format mailing list
> Kolab-format at kolab.org
Developer, Kolab Systems AG
e: wrobel at kolabsys.com
t: +49 700 6245 0000
pgp: 9703 43BE
This message was sent using IMP, the Internet Messaging Program.
More information about the format