KDateTime: next iteration

[Nicolas Goutte]

On Monday 28 November 2005 21:50, Thiago Macieira wrote:
> David Jarvie wrote:
> >I attach another iteration of the KDateTime header. The implementation
> > file is at http://www.astrojar.org.uk/linux/download/kdatetime.cpp.
> > This now incorporates all 5 types of "time zone" information which has
> > been discussed:
> >  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")

See the past discussion on KDateTime

>
> >   Time zone
> >   Local time zone (a special case of "Time zone")
>
> Ok for special case
>
> >   Local clock time (no time zone)
>
> This doesn't make sense to me. What's the rationale behind it? 

Please look at the past discussion.

It is simply the wall time where the timezone is not known.

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.

> Every time
> must be associated to a timezone, unless we're talking about time
> differences.

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

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

Have a nice day!