KDateTime: new revised version

[David Jarvie]

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

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.

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

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