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

Perhaps for FISH a solution could be found when trying harder.

But there are other KIO slaves that have no idea about the timezone or the 
time offset of the dates in the files, for example zip and tar, but also 
floppy or mac. Probably the only thing that could be told is that the time 
was local on the system having written those files.

Similar to other office documents. The dates/times are supposed to be local 
but the document does not give any clue in which timezone the dates/times 
were written, or at least with which time offsets.

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

May be we misunderstood us here. I was talking about a possible change of 
Konqueror, assuming that KIO slaves would be changed too, to allow KDateTime 
to be passed. (I do not think that it is planned now.) So there would no need 
over converting to seconds-to-epoch.

>
(...)

Have a nice day!