KDateTime: new revised version

[Nicolas Goutte]

On Sunday 27 November 2005 01:31, David Jarvie wrote:
> On Saturday 26 Nov 2005 22:45, Nicolas Goutte wrote:
> > On Saturday 26 November 2005 22:52, David Jarvie wrote:
> > > On Saturday 26 November 2005 17:24, Nicolas Goutte wrote:
> > > >On Friday 25 November 2005 13:28, David Jarvie wrote:
> > > >> On Friday 25 November 2005 11:30, Shaheed wrote:
> > > >> >On Thursday 24 November 2005 13:13, Nicolas Goutte wrote:
> >
> > (...)
> >
> > > >So to start again the discussion on a clean base.
> > > >
> > > >A QDateTime which is Qt::LocalTime should be transformed by default to
> > > > a KDateTime having the current system's timezone. (Of course, the
> > > > other constructors can have parameters to tweak such a transformation
> > > > in a different way.)
> > > >
> > > >To be back to the answer above, I think that a date/time with an
> > > > offset is different than a pure UTC date, especially because it has
> > > > an offset. (As I have wriiten in an answer to Shaheed's private
> > > > email, nobody would buy clocks and watches if they could only display
> > > > UTC.)
> > > >
> > > >Also for KDateTime, for member function returning if the date/time is
> > > > UTC, a date with a non-zero offset should return false. Similarly the
> > > > member function for testing if it is a local time (in the sence of
> > > > QDateTime) should return false too (as we do not know if the offset
> > > > corrsepond to the system's timezone, even if perhaps the time offset
> > > > would match.)
> > > >
> > > >Of course perhaps there would be another member function for testing
> > > > if a date
> > > >is neither UTC nor the local time (again in QDateTime's sence). For
> > > > such a function, a dtae/time with non-zero offset should return true.
> > >
> > > If it is not considered to be UTC, then if the date/time component is
> > > returned via dateTime(), it would return the "local" time (i.e. the UTC
> >
> > So if I understand you well, you want to keep the QDateTime behaviour in
> > KDateTime.
> >
> > However I find it limiting, as it would be difficult to tell what kind of
> > KDateTime you currently have: a local date/time (in QDateTime's sence), a
> > real UTC date/time, a date/time with a named timezone or a date/time with
> > a time offset.
>
> We would actually have 5 separate types of KDateTime:
>    UTC
>    Offset from UTC
>    Time zone
>    Local time zone (a subset of "Time zone")
>    Local clock time (no time zone)
>
> I agree with you that there needs to be a way to determine whether a
> KDateTime instance contains a UTC offset or not. A type() method returning
> an enum value would, I think, be the obvious way. But we could still retain
> isUTC(), etc. in addition. And of course there should be a method to return
> the value of the UTC offset.

Yes!

Have a nice day!