KDateTime: new revised version

[Nicolas Goutte]

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.

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

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

>
> Shaheed

Have a nice day!