[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Proposed new KDateTime class
From:       Nicolas Goutte <nicolasg () snafu ! de>
Date:       2005-11-09 10:41:28
Message-ID: 200511091118.42344.nicolasg () snafu ! de
[Download RAW message or body]

On Tuesday 08 November 2005 23:52, David Jarvie wrote:
> On Tuesday 08 Nov 2005 22:40, Nicolas Goutte wrote:
> > On Tuesday 08 November 2005 23:00, David Jarvie wrote:
> > > Now that the time zone classes have been updated, there is a need to be
> > > able to handle date/times which have an associated time zone. I attach
> > > a proposed new kdecore class, KDateTime, which represents a date/time
> > > with an associated time zone. The aim is to make time zone handling as
> > > automatic as possible when manipulating dates and times. Its interface
> > > is very similar to QDateTime, but it is not inherited from QDateTime
> > > mainly because QDateTime's methods are not virtual.
> > >
> > > The code compiles, but I until I finish the test program is untested.
> > > Note that if the new class is committed, the time zone classes will
> > > need to be amended to handle the new class.
> > >
> > > Comments please. (Note that I am going away and won't be able to
> > > respond for a few days.)
> >
> > 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.)

Have a nice day!

[prev in list] [next in list] [prev in thread] [next in thread]