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

[Gunnar Wrobel]

Hi Hendrik,

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
>> all.
>>
>> *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
> components?
> 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  
direction.

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.

Cheers,

Gunnar

>
> Best regards,
>
> Hendrik
>
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at kolab.org
> https://kolab.org/mailman/listinfo/kolab-format
>



--
Gunnar Wrobel
Developer, Kolab Systems AG

e: wrobel at kolabsys.com
t: +49 700 6245 0000
w: http://www.kolabsys.com

pgp: 9703 43BE

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.