KDateTime: new revised version

[David Jarvie]

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.

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, 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.

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