localtime +tz-id how to store

[Bernhard Reiter]

Am Freitag, 1. April 2011 11:57:04 schrieb Georg C. F. Greve:
> 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.

> 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.

For the datetime stamps in the past and present, we do not need to store 
localtime + tz-id at all. As appointment start and end times are usually in 
the future, we use it there always. As for creation-date, we use UTC only.
At least this sound sensible to me.

> 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.

In the case of non-UTC data, with the current status of the KEP,
all clients will a have to do the extra implementation steps
to conform with the KEP. You could change the KEP to say
that only tags, X, Y, Z, you need to follow the tz-id preferance
or only in some other cases. But as it stands now, those partial clients
cannot be sure of the offset to be correct.

> 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.

rfc3339 + tz-id is something new for many arguments you have presented.
My proposal is iso compliant.

> 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.

Well the parsing functions are iso compliant mostly, of course
they can parse a substring of our newly proposed formats a) and b).
The problem is to comply with the additional rules, which are part
of our "format". You always have to craft code around it, so you already have 
to build your own parser logic for tz-id for a) and b).

> 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.

Using an explicit rfc3339 writing function 
makes variant a) being equal with b) on writing.
This does not help for reading, though.


-- 
Managing Director - Owner: www.intevation.net       (Free Software Company)
Deputy Coordinator Germany: fsfe.org. Board member: www.kolabsys.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110401/ab50d6cf/attachment.sig>