KDateTime: next iteration

[Nicolas Goutte]

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.

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. 

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.

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.

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.

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

Have a nice day!