KDateTime: new revised version

[Nicolas Goutte]

On Friday 25 November 2005 07:19, David Jarvie wrote:
> 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.

It sounds good.

Also meanwhile I think that it is more the Doxygen doumentation about this 
enum value that will be important than its name (as probably a third point of 
view would suggest again another name for it).

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

Yes, perhaps.

Have a nice day!