KDateTime: next iteration

[David Jarvie]

On Tuesday 29 November 2005 14:00, Nicolas Goutte wrote:
>On Tuesday 29 November 2005 14:37, David Jarvie wrote:
>> On Tuesday 29 November 2005 11:52, Nicolas Goutte wrote:
>> >On Tuesday 29 November 2005 11:46, Nicolas Goutte wrote:
>> >> On Tuesday 29 November 2005 11:11, Thiago Macieira wrote:
>> >> > Nicolas Goutte wrote:
>> >> > >On Monday 28 November 2005 21:50, Thiago Macieira wrote:
>> >> > >> David Jarvie wrote:
>> >> > >> >  UTC
>> >> > >> >   Offset from UTC
>> >> > >>
>> >> > >> What's the difference between those two? UTC is UTC + 0 (or -0, if
>> >> > >> you'd rather), so it's the same as an offset from UTC.
>> >> > >
>> >> > >07:20 +0000 (UTC) is not the same as 08:20 +0100 ("Offset from UTC")
>> >> >
>> >> > So we have 1500 types of timezones? One for each possible minute of
>> >> > the 25-hour span of timezones?
>> >>
>> >> No, we have simply a time offset. That is the current state of the
>> >> discussions.
>> >>
>> >> > I thought David listed 5 types.
>> >> >
>> >> > >It could become useful for example if Konqueror uses KDateTime
>> >> > > instead of seconds since the epoch. In that case, you can use it in
>> >> > > the FISH KIO slave to tell that you have no idea about the timezone,
>> >> > > as it is an information thatthe FISH protocol does not transmit.
>> >> >
>> >> > FISH should be modified to transmit it. All it has to do is set TZ=UTC
>> >> > before sending anything.
>> >>
>> >> Well, as far as I understand, FISH is supposed to work with other FISH
>> >> servers. (However I am not sure if it is really supported now).
>> >>
>> >> Also I am not sure that the TZ trick works on Windows. (However there,
>> >> /dev/ null is probably a problem too, as reported.)
>> >>
>> >> Of course, FISH is only an example. I am sure that there are other
>> >> cases. (I can think about RFC 2822's -0000 time offset.)
>> >
>> >The difference is that KDateTime considers such a time being by default a
>> >local time, while RFC 2822 assumes that such a time is UTC.
>>
>> RFC 2822 says:
>>    The form "+0000" SHOULD be used to indicate a time zone at
>>    Universal Time.  
>
>> Though "-0000" also indicates Universal Time, it is
>
>So by default it is considered to be a UTC time...
>
>>    used to indicate that the time was generated on a system that may be
>>    in a local time zone other than Universal Time 
>
>... even if the real local time zone is not given.
>
>> and therefore
>>    indicates that the date-time contains no information about the local
>>    time zone.

I would interpret it to mean that it can be treated as UTC, but it very likely is a local time of unknown 
zone. In other words, the time zone is actually uncertain. Which is the equivalent of local clock time.

>However what I see from KDateTime is that ClockTime is considered local time. 
>(already in KDateTimePrivate::toUtc where it is very clear.)

It's considered as local time on whatever system it happens to be being processed on. So it is a different 
moment of time on different systems if they are operating on different time zones.

FWIW, this is the mandatory interpretation of a local time in RFC2445.

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