localtime +tz-id how to store (Re: A summary of sorts (was: Re: Why and when storing local time?))

Georg C. F. Greve greve at kolabsys.com
Fri Apr 1 11:57:04 CEST 2011

On Friday 01 April 2011 09.47:38 Bernhard Reiter wrote:
> With the above implementation rules explained, I believe the two example
> strings for a) and b) both can be considered to represent a "new" notation
> for storing local time. 

While I appreciate the argumentative attempt, I think that is stretching 
imagination quite far. 

RFC3339 is explicitly geared to store local time with an offset to UTC. 

Local time storage is in fact the only reason that it allows such offsets.

It is true that it explicitly does not address the DST issue to not make 
RFC3339 overly complex, but it still solves two of three cases perfectly, 
namely for datetime stamps in the past and present. 

These will be written with the correct offset and can be used by scripts and 
other partial clients that have limited requirements to use/manipulate the 
data set, so this group of applications will not need to handle TZ-ID, at all.

The case where RFC3339 falls short is the future, and the TZ-ID provides a 
solid solution in this case where we supplement the existing standard with the 
functionality we require, instead of inventing something entirely new.

We had several people confirm that RFC3339 parsing is no issue in their 
programming language, e.g. Gunnar for PHP. I know Python handles it, so do 
other languages, even shell scripts through the GNU core utilities.

That Qt, which is largely a widget toolset, does not support RFC3339 does not 
come as a major surprise to me, to be honest. Time handling is typically a 
system or programmling language level function, and not something I'd expect 
in the graphical toolkit any more than I'd expect it to do SMTP.

In either case there is at least one usable reference we could re-use for 
Kontact if all else fails, namely the GNU date utility, which explicitly 
supports RFC3339.

Re-use of something as well tested as a core GNU utility for one client always 
seems preferrable over inventing something new and writing a plethora of new 
parsers for it for all sorts of programming languages and Kolab components.

Best regards,

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/20110401/f9fd2dfc/attachment.sig>

More information about the format mailing list