KDateTime: new revised version

[Shaheed]

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.

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

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.

Shaheed