KDateTime: next iteration

[David Jarvie]

On Tuesday 29 Nov 2005 17:30, David Jarvie wrote:
> 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:
> >> >> 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.
...
> >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.
...
>
> 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.)

I asked on the kdepim list about this, and Ingo Klöcker gave the following 
information about kmail's handling of -0000 times:

<<<<<<quote>>>>>>
RFC 2822 says:
   Though "-0000" also indicates Universal Time, it is
   used to indicate that the time was generated on a system that may be
   in a local time zone other than Universal Time and therefore
   indicates that the date-time contains no information about the local
   time zone.

IOW, we should try to guess the correct time zone from other information
(e.g. the first Received header). Currently we don't do this in KMail.
In fact we are using KRFCDate::parseDate() from kdelibs. And this one
doesn't seem to handle "-0000" other than "+0000".
<<<<<<end quote>>>>>>

I don't yet have information about how other applications handle it. But it 
looks like there is probably a need to be able to transform -0000 times into 
other time zones. The KDateTime class already provides facilities to do this, 
so I don't know whether any changes are needed.

> >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 and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html