KDateTime: new revised version

[Nicolas Goutte]

On Sunday 27 November 2005 12:34, Shaheed wrote:
> 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?

Sounds better!

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

Yes, indeed. I cannot see a situation where it would be really needed.

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

Well, it depends how you see the problem.

We can put data which has (some) sence. For the latitude, the equator (0°) 
seems to be natural and, as for the comment, well, we can put the time 
offset.

Of course, this make it more a mathematical abstraction but if we "map" time 
offset to pseudo-named-timezones, it would be a mathematical abstraction too.

>
> Shaheed

Have a nice day!