KDateTime: new revised version
nicolasg at snafu.de
Tue Nov 29 10:24:53 GMT 2005
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?
> > > 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
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.
Have a nice day!
More information about the kde-core-devel