KDateTime: new revised version

[David Jarvie]

On Thursday 24 Nov 2005 17:26, Nicolas Goutte wrote:
> On Thursday 24 November 2005 16:01, David Jarvie wrote:
> > On Thursday 24 November 2005 13:13, Nicolas Goutte wrote:
...
> > Perhaps this points to the need for the class to handle two different
> > types of local time. One would be a local time in the sense of using the
> > local system's time zone (so that the time would be the same instant no
> > matter which machine you copied it to), and the other would be local time
> > in the sense of ignoring time zone and just using the local system's
> > clock time.
> >
> > There could then be a new TimeSpec enum to feed to constructors, namely
> >    UTC - same as Qt::UTC
> >    LocalZone - a convenience way of setting the time zone to
> > KSystemTimezones::local(), i.e. the system time zone in use when the
> > constructor was called.
> >
> >    LocalClock - a time which ignores time zones and just uses whatever
> > the system clock says.
>
> Instead of putting an uncertainty on the meaning of local time, it would
> perhaps be better to call this "IgnoreZone" or something similar. That
> would be clearer.

How about ClockTime? I'd prefer to see the name include "Clock" somehow.

> > >May be my comments were more about processing already exisiting dates,
> > > but for my use case of KBabel, I need too to create a date from the
> > > current date/time and write in the saved Gettext PO file. And KBabel's
> > > catalog manager will need to read that date again (and probably another
> > > too). And whatever loading and saving it will be with a numeric offset
> > > (except very old PO files). However I suppose that the user would
> > > prefer his/her local time displayed but at load the date in the file
> > > will be in any arbitrary numeric offset. As for saving, Gettext PO
> > > files are traditionally saved with the local date/time of the user
> > > (including numeric offset). (Sure may be the offset/timezone could be
> > > invalid in a file and to be able to keep the date neveretheless could
> > > be an interesting idea (while indicating an unknown timezone to the
> > > user).)
> >
> > Perhaps for UTC date/time values, we need to be able to store a UTC
> > offset. That way, the full ISO 8601 information is preserved, even though
> > the time zone is unknown.
>
> Yes, it would perhaps a way to store it internally. As long as
> KDateTime::toString gives useful strings (so again a date/time using the
> offset), I do not mind.
>
> However I suppose that such a date should not return true for the isUTC
> function.

I think that instead of isLocalZone(), isUTC(), etc., there should be a type() 
method which returns an enum with values { UTC, UTCOffset, LocalZone, 
TimeZone, ClockTime }. This is a superset of what can be passed to the 
constructor.

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