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
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.
Georg C. F. Greve
Chief Executive Officer
Kolab Systems AG
e: greve at kolabsys.com
t: +41 78 904 43 33
pgp: 86574ACA Georg C. F. Greve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 308 bytes
Desc: This is a digitally signed message part.
More information about the format