KDateTime: new revised version

[Shaheed]

On Sunday 27 November 2005 10:28, Nicolas Goutte wrote:
> If we have to choose, then I think that this is clearer. (Even if I do not
> like the RFC2822 part in the class name, as time offsets are not at all
> RFC2822-specific.)

How about KOffsetTimezone* then?

> > In both cases, the implication is that the toString()/fromString()
> > methods in KTimeDate would be delegated to an appropriate KTimezone
> > subclass using a virtual method.

I think the key question remaining is whether David thinks this makes sense 
(since he owns KDateTime and the other relevant classes).

> > The latter would allow apps to easily convert between the two, but would
> > imply that different entries from different sources would not always have
> > the same info
> >
> > (since the RFC2822 entries would not, for example, have
> > meaningful longitude values).

> For longitudes, we can use the time offset. We know that UTC+0 is at 0°,
> UTC+12 at 180° East and UTC-12 at 180° West.
>
> So we would use a formula like
> longitude = offset * 180 / 12
> with the offset in hours.
>
> So the longitudes would be meaningful in a mathematical sence.

Ok, ok :-) Read "latitude" or "comment" instead...but I think you get my 
general point.

Shaheed