KDateTime: new revised version

[David Jarvie]

On Sunday 27 Nov 2005 11: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).
>
> > > 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

If we introduced a KOffsetTimezone class, it would be quite a simple class. 
Because it wouldn't be possible to convert easily between it and KTimezone, 
I'm not sure whether it would really be useful. Would it actually have any 
standalone uses, or would it be sufficient for KDateTime to handle it 
internally? Who would actually want to do any calculations involving it, 
other than via KDateTime? KTimezone (and its derivatives) are needed because 
processing real time zones is quite complex, but I remain to be convinced 
about KOffsetTimezone.

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

Bear in mind that KSystemTimezone and ICalTimezone, both derived from 
KTimezone, don't have latitude, longitude or comment. Most of the "standard" 
data in KTimezone, except for that which is strictly necessary to interpret 
time zones, so far relates only to KTzfileTimezone, and is missing from the 
other derived classes which currently exist because the information isn't 
available. The non-essential data is very much a function of the particular 
source data - for example, ICalTimezone (which represents iCalendar time 
zones) has data fields for URL, city name, and a comment for each individual 
standard/daylight savings definition in the time zone.

-- 
David Jarvie.
KAlarm author and maintainer.
http://www.astrojar.org.uk/linux/kalarm.html