KDateTime: new revised version

[David Jarvie]

On Saturday 26 Nov 2005 21:52, David Jarvie wrote:
> On Saturday 26 November 2005 17:24, Nicolas Goutte wrote:
> >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
> time plus the UTC offset). For example, if the time was [date] 02:00 +0300,
> then dateTime() would return a time part of 05:00. In this case, I would
> probably store the time as a local time (i.e. Qt::LocalTime) of 05:00, and
> then the UTC offset would as I previously proposed only ever be used by
> toString() which would for an ISO 8601 format return [date] 02:00 +0300.

Oops, I had things mixed up. A time of 05:00 +0300 would always display as 
05:00 because that is the local time. It is equivalent to 02:00 UTC. So 
actually, 05:00 would be stored as a local time in the date/time component of 
the KDateTime, and the UTC offset just gives the effective "time zone".

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