From kde-core-devel  Mon Nov 14 00:51:41 2005
From: David Jarvie <lists () astrojar ! org ! uk>
Date: Mon, 14 Nov 2005 00:51:41 +0000
To: kde-core-devel
Subject: Re: Proposed new KDateTime class
Message-Id: <200511140051.42553.lists () astrojar ! org ! uk>
X-MARC-Message: https://marc.info/?l=kde-core-devel&m=113192962009742

On Wednesday 09 Nov 2005 10:41, Nicolas Goutte wrote:
> On Tuesday 08 November 2005 23:52, David Jarvie wrote:
> > On Tuesday 08 Nov 2005 22:40, Nicolas Goutte wrote:
> > > Do you plan something like QDateTime::toString and
> > > QDateTime::fromString for ISO dates, including time zone handling?
>
> I forgot: it is ISO 8601, see Wikipedia's article:
> http://en.wikipedia.org/wiki/Iso_date
> (Of course, we need only the normaly used date formats. Weeks, time
> intervals and durations are probably not needed. (Well, KOffice would
> perhaps like durations too, but I am not sure if it can/must be in the same
> class.))
>
> > > (Also, I am not sure how flexible such functions need to be, I would
> > > need such them for KBabel saving and loading Gettext PO files.)
> >
> > Yes, it would be a good idea. There would need to be an extension to the
> > format codes to be able to specify where and in what format the time zone
> > should appear. I suggest that the default format would append the
> > abbreviated code for the time zone to the end of the string.
>
> The default should not be a time zone code, but the time zone offset.
> (Only Z exists as time zone code in ISO 8601, the rest is marked as
> offset.)
>
> (The main problem is that timezone codes are not unique.)

I wasn't aware of the ISO standard, but since it exists, it would obviously be 
a good idea to use it in toString() and fromString(). Is there a need for 
time zone codes such as EDT, BST, CET to be catered for as well, or can we 
ignore them?

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html