KDateTime: new revised version

[Shaheed]

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

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

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

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

> I do not mind the internal representation. What I would like is that for
> interaction with other formats than the internal formats, that the time
> offset is not lost (unlike what Shaheed seems to prefer).

My preference is for the separate sources. I think that would nicely address 
this limitation of my previous thinking.