KDateTime: new revised version

[Nicolas Goutte]

On Thursday 24 November 2005 16:01, David Jarvie wrote:
> On Thursday 24 November 2005 13:13, Nicolas Goutte wrote:
> >On Thursday 24 November 2005 13:40, Shaheed wrote:
> >> On Thursday 24 November 2005 10:55, Nicolas Goutte wrote:
> >> > > I think that there is some confusion over what "local time" means.
> >> > > Local time is just the time on the system clock. It knows and cares
> >> > > nothing about time zones.
> >> > > Say you have a local time of 22:30 on 1st January 2006. The
> >> > > current system might be running on GMT (+0000). Then somebody in the
> >> > > USA uses that time. It is still 22:30 on 1st January 2006, but now
> >> > > it is EST (-0500). So on the two systems, the times occur 5 hours
> >> > > apart even though they are represented in the same way.
> >> > > Local times are used for such vital
> >> > > things as "I don't care where in the world I am, but I want to get
> >> > > up at 7.30 am so that I don't miss my breakfast".
> >> >
> >> > That is perhaps a fine answer in an offline world but computers are
> >> > not offline (or not always offline).
> >> >
> >> > Not knowing what timezone the local time has, can create subtle bugs
> >> > (e.g. the one in the fish: KIO slave).
> >> >
> >> > What you tell is only that the timezone is implicit; however even
> >> > being implicit, it is still existing.
> >>
> >> The problem is that "-0500" does not convey enough information to allow
> >> one to know what that implicit timezone is. One could make some guess
> >> that "-0500" describes a local time near the East Coast, but one cannot
> >> be sure what the timezone is in which the local timestamp originated.
> >
> >Well, when I look in /usr/share/zoneinfo I see that there is a directory
> > Etc with many numbered timezones.
> >
> >So I suppose that at least somebody thinks too that numbered timezones are
> >good enough. (However I would prefer a solution without needing the
> > presence of such timezone data files.)
> >
> >But that was not really the problem here. We were talking about local
> > times.
> >
> >When you have a local time, it is not a time with an unknown time zone.
> > There is a difference between the two concepts.
>
> 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.

>
> Once constructed, the KDateTime instance would still just have the same
> possibilities as currently, i.e. UTC, a time zone, or a local clock time
> which ignores time zones. KDateTime(...,LocalZone) would create a KDateTime
> instance with a time zone.
>
> The isLocal() method should then be renamed to isLocalClock(), and a new
> method added called isLocalZone() which would return true if the time zone
> instance is equal to KSystemTimezones::local ().
>
> >> > Also by making local time being an unknown timezone, this class
> >> > behaves differently than from the C library and from QDateTime.
> >>
> >> I'm not sure that either the C RTL or Qt can take a timestamp which came
> >> from the East Coast ("-0500") and convert it into a {datetime, timezone}
> >> when the computer on which the library is executing is not the one where
> >> the timestamp originated.
> >
> >Here we were not talking about converting arbitrary numeric timezones but
> > we were talking about the concept of "local time".
> >
> >Qt4's QDateTime has:
> >QDateTime QDateTime::toUTC () const
> >QDateTime QDateTime::toTimeSpec ( Qt::TimeSpec specification ) const
> >QDateTime QDateTime::toLocalTime () const
> >
> >So Qt4 does *not* consider local time as being without time offset. (As
> > for Qt3, we could perhaps argue on this point.)
> >
> >And in the C library you have localtime(3) and gmtime(3). And there is
> > also mktime(3) will convert a local date into the correct offset since
> > the epoch (which is UTC).
> >
> >> I think a key difference here is that Nicolas seems to be thinking of
> >> timestamps generated and manipulated locally, whereas David seems to be
> >> thinking of timestamps generated in one place and used somewhere else.
>
> The reason that I wanted to create the KDateTime class (and the recent
> modifications to the KTimezone classes) comes from the need to be able to
> handle PIM calendar data containing time zone definitions. Often calendars
> will originate on a different system. As soon as you need to handle more
> than just the local time zone, Qt's date/time facilities (even in Qt 4)
> just aren't up to it. But the problem isn't limited to PIM calendars - it
> is really the same no matter what type of application you are dealing with.
> Hence a kdelibs class rather than a kdepim library class.

Yes, the problem is general enough and Qt4 does not go far enough.

(That is why I am interested in common code to replace the ones already used 
in KBabel and to avoid to create new ones in KDE4 for KBabel.)

>
> >Yes, perhaps. But when the date is used somewhere else, it needs to be
> >processed there too. (For example KMail, calculates a date here, but
> > another KMail needs to read it again there.)
> >
> >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.

>

Have a nice day!

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