Proposed new KDateTime class

[Nicolas Goutte]

On Monday 14 November 2005 01:51, David Jarvie wrote:
> 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?

Personally I do not know. For KBabel, I can live without it. Old PO files 
(like some old ones in Gettext) have still a time zone code, but for the use 
that I plan, it is not mandatory to be able to read them. (So if it is easy 
to add fine, if it make too much work, not a problem for me either.)

Have a nice day!