KDateTime: new revised version

[David Jarvie]

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.

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