KDateTime: next iteration

[Nicolas Goutte]

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.)

(Also Python seems to have implemented its datetime class that way too and 
calls such date/times "weak" as far as I have understood the documentation.)

>
> >> Or unless we're talking about an "unknown" timezone (which
> >> means this should fall into the "Local time zone", which is in turn a
> >> special case of "time zone").
> >
> >I do not think so. It is better to be allow to tell the user that the
> > timezone is unknown than to force it to UTC or to local time (in
> > QDateTime's sence).
>
> I don't agree. We should keep in mind that this time will get transformed
> into the standard UTC-seconds-since-epoch of Unix time, so this
> information will be irreparably lost.

Well, that is the same problem as the -0000 offset of RFC 2822.

So if you really need the conversion, then you assume that the time is UTC and 
convert it. You cannot do better.

>
> The only case I can think of KDateTime doing this distinction would be if
> it provided comparison operators (in that case, "01:00 unknown" > "00:00
> UTC" as well as "00:00 GMT-1") or if it provided elapsed-time operators
> (you cannot tell how much time elapsed from "unknown" to "known"
> timezones).

Well, KDateTime is only starting. So perhaps somebody will implement that (be 
it in kdelibs or not).

>
> >> So, by my account, there are only two types:
> >> 1) offset-only
> >> 2) detailed (with latitude, longitude, name and DST historic)
> >
> >But then you completely lose comaptibility to QDateTime, which is not
> > wanted.
>
> That's not what I meant. From the discussion, it seemed we're talking
> about backends to store information. We have only 2 (or 3, with the
> "unknown" type) backends.

We have 5 cases:
- UTC (compatiblity to QDateTime)
- local time (system's timezoine, compatiblity to QDateTime)
- named timezones (that is why the KDateTime class was created for.)
- time offset (needed as modern time specification like RFC 2822 or ISO 8601 
have only time offsets, no named timezones).
- unknown (for cases where we cannot define the timezone)

>
> I raised this issue specifically to make sure we don't create unnecessary
> backends.

I too had started by thinking that a unknown time zone was not needed. But 
thinking about it, I think it is needed, even if not for all needs.

Have a nice day!