KDateTime: revised version

[David Jarvie]

On Thursday 24 November 2005 11:11, Nicolas Goutte wrote:
>On Thursday 24 November 2005 11:49, David Jarvie wrote:
>> A time zone has information about daylight savings time changes, and allows
>> you to calculate the elapsed time between two clock times in that time
>> zone, etc. A numbered "time zone" says nothing about daylight savings time
>> changes, so a simple UTC offset is just a way of representing an absolute
>> time. If you know that somebody sent you an email at "20:30, 31st March
>> 2004 +0300", you don't know what their clock time would be 100000 minutes
>> later because they might or might not have passed through a daylight
>> savings change. Only the time _zone_ can tell you that.
>
>Personally I do not mind that you would map it to UTC.
>
>However I suppose that a user would be more able to read a date/time with one 
>hour offset than one that has the full offset to UTC.
>
>(And for my use case of PO files, I really cannot create a named timezone for 
>it, and I suppose that the kdepim developers will have the same problem in 
>many situations. So one can only read a date/time with a numeric offset and 
>try to convert it to the local time of the user (or of a time zone that the 
>user has chosen instead, e.g. UTC.))

Some kdepim developers (e.g. KMail) will certainly encounter UTC offsets. But others (e.g. 
KOrganizer) will normally handle named time zones which are either fully defined in the calendar 
file, or (hopefully) defined in the system.

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