KDateTime: new revised version

[Nicolas Goutte]

On Thursday 24 November 2005 11:19, David Jarvie wrote:
> On Thursday 24 November 2005 7:44, Nicolas Goutte wrote:
> >I have looked at the code this time.
> >
> >I am not sure about how the local time is transformed to a string. I think
> > it would be more useful to find the right time zone and to output the
> > right time zone in the string.
> >
> >Especially for RFC 2822, where, as far as I know, the -0000 means more
> >something like: "The OS is too stupid to know its local time zone."
>
> 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.

Also by making local time being an unknown timezone, this class behaves 
differently than from the C library and from QDateTime.

However on one point you are right. The code using this class might be forced 
to tell that it really does not know the timezone. But I do not think that 
the local time should be used for that. (Python's datetime class seems to use 
None for that, but that is not a possible solution for C++.)

>
> So, "local time" is not the same as "local time zone" which you can access
> by KSystemTimezones::local(). If you want to arrange a phone call to your
> USA friend at 22:30 on 1st January 2006 on your system clock, you would
> fetch you local time zone (GMT, +0000) and then send the other person
> "22:30 on 1st January 2006 +0000" or "22:30 on 1st January 2006 GMT" or
> "22:30 on 1st January 2006 Europe/London". That way you would both expect
> the call at the same time, but for one person their local clock time would
> be 22:30 and for the other, 17:30.

I think that our misunderstanding is that I thought that this class was 
closely related to KTimezones. I discover (not only due to this email) that 
it is not and I do not find it good.

So if you have planned to make KDateTime unrelated to KTimeZones, then perhaps 
the best would be either to move the date/time functions reading or writing 
strings to KTimezones or to create a third class for them.

>
> >Also for IS0 8601 dates, perhaps the timezone should be nothing instead of
> > a space.
>
> For local time, the time zone is supposed to be nothing for an ISO 8601
> date. AFAICS, the code doesn't output a space.

I have read again the Doxygen comments. I suppose that I have misread "blank". 
Sorry!

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

Have a nice day!