KDateTime: new revised version

[Nicolas Goutte]

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.

> 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.
>
> >A little side note: perhaps we must be careful what the UTC checking
> > function returns in the case of a UTC timezone like UTC, Zulu, Universal,
> > UCT, GMT and all the other alternative names (already the Etc
> > subdirectory seems to have them all again). (I have not checked the
> > current code to see if it already return true in such cases.)
>
> I don't think that we can return "UTC" unless it is constructed with a UTC
> specifier, or if it is constructed with the KTimezones::utc() KTimezone.
> Otherwise, we can't be sure that it really is UTC, and would return false.

Yes, probably documenting this problem is enough for now.

> (It might in addition be possible to add a function to KTimezone to check
> whether a time zone is UTC, i.e. that it always has a UTC offset of zero,
> and never undergoes any daylight savings changes. Then we could call that
> function to find if it was UTC.)

And if somebody wnts really to make all this work, it can be added later in 
any KDE 4.x.


>
(...)
>
> --
> David Jarvie.
> KAlarm author & maintainer.
> http://www.astrojar.org.uk/linux/kalarm.html

Have a nice day!