KDateTime: next iteration

[David Jarvie]

On Tuesday 29 November 2005 15:19, Nicolas Goutte wrote:
>On Tuesday 29 November 2005 15:13, David Jarvie wrote:
>> 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.
>
>I have looked quickly at RFC 2445.
>
>(By the way, it uses leap seconds, at least second 60 but not 61.)
>
>I do not see a -0000 in RFC 2445, especially as time offset are not allowed in 
>RFC 2445, as far as I understand.

Correct. I wasn't talking about the syntax - rather, I was talking about the concepts used.

>RFC 2445 defines local for no time zone and UTC for Z and a named timezone for 
>the rest. That is basically the basic design of the first versions of 
>KDateTime. 

That's the point I was trying to make.

>However this class is for kdelibs, so I do not think that a class in kdelibs 
>should be thighly linked to a single RFC, especially if another RFC has other 
>concepts.

I was only illustrating the fact that local clock time is required by some specifications, so 
KDateTime needs to cater for it.

>RFC 2822 is about email transfer. In such a task you cannot afford to have a 
>different read of a time from system to system. So if the timezone is 
>unknown, it becomes UTC. (The - sign is a warning to take the date with 
>care.)
>
>You can also look at RFC3339, section 4.3, which is about -00:00 in ISO8601.
>
>>
>
>However I do not know what we should do. 
>
>Creating a date/time class for RFC 2445 and another for RFC2822/ISO8601 (not 
>counting KStars) seems stupid at first glance. (Probably KStars could use the 
>same class than RFC2822/ISO8601, as time offsets are not new, even if it is 
>only the railway that showed the problem and lead to coordinated times.)
>
>Creating a 6th mode for KDateTime (date/time of unknown timezone, assume UTC) 
>is probably not a solution either.

I still dispute your interpretation that UTC should be used is stated unambiguously in 
RFC2822. I think that only somebody who is really familiar with using RFC2822 can say for sure.

But regardless, I don't see any argument for a 6th mode. At the worst, an extra enum value for 
fromString() might be needed - to specify whether RFC2822 format should return a clock time or 
UTC when it encounters -0000. We're not talking about a new mode - it's simply a question 
of "do we use local clock time, or do we use UTC?" For RFC2822, I think that we need 
clarification about how it is actually used in practice. (Of course, it's always possible that 
different implementations make different interpretations, but that, as I say, is not really a 
problem.)

>The last idea that I have is to transform the "weak" idea of Python, but to 
>allow any of the four other modes of KDateTime. So a weak date could be 
>assumed to be UTC, assumed to be local time or assumed to whatever timezone 
>or time offset needed (if there is possibly a hint somehow).
>
>I really do not know in what direction we should go, as somehow we start 
>approaching feature bloating, on the other side what is assumed by different 
>RFCs will probably be needed here or there one day or another.

It could be left to the application to decide that it doesn't like local clock times, and to 
transform any such KDateTime instances to whatever else it likes. Or we could perhaps provide 
a settable default when local clock time isn't allowed. But then of course there's the problem 
of an application which works with more than one data source, where the different data sources 
conflict in their requirements. So perhaps we should just leave it to the application to 
transform things. The basic mechanisms are all there in the current proposal. I think that all 
we might need is a new enum value for fromString().

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