KDateTime: new revised version

[Nicolas Goutte]

On Sunday 27 November 2005 10:41, Shaheed wrote:
> On Saturday 26 November 2005 17:24, Nicolas Goutte wrote:
> > So to start again the discussion on a clean base.
>
> Heh. Before I saw your note, I was worrying about restarting this thread! I
> also have a new idea for your consideration.
>
> First, let's make the working assumption that "1-Jan-2006 -0500" does in
> fact specify a first-class timezone (in the sense of a KTimezone). What
> does that mean? To me, this suggests either that:
>

> - alongside the KTzfile* implementation of a system timezone we could have
> a KRfc2822* implementation

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

>
> - or, we could *add* to the tzfile implementation of "Region/Locality"
> style names, a set of "RFC2822/offset" names.

We would need 24 * 60 pseudo-timezones. That is perhaps a little too much. 

>
> 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.
>
> There are pros and cons to both approaches. The former allows a clean
> separation between the two types of timezone with well-defined semantics
> for each. KOrganizer would use one, KBabel the other. 

> But any conversion
> between them would require application-specific thought/implementation *if
> such conversion is even needed*.

Conversion in the direction time offset to named timezone are going to be 
complex, whatever the implementation of KDateTime. So probably such a 
conversion should be in a special class.

But I agree with you that somebody should come up with a useful case where it 
is needed.

(As for the other direction, KDateTime will need it often for toString but it 
probably does not need such a conversion in a rather formal way.)

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

>
(...)

Have a nice day!