KDateTime: new revised version
lists at astrojar.org.uk
Sun Nov 27 16:34:39 GMT 2005
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
> > > (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.
KAlarm author and maintainer.
More information about the kde-core-devel