[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDateTime: new revised version
From:       Shaheed <shaheed.haque () kdemail ! net>
Date:       2005-11-27 11:34:37
Message-ID: 200511271134.37690.shaheed.haque () kdemail ! net
[Download RAW message or body]

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

[prev in list] [next in list] [prev in thread] [next in thread]