KDateTime: new revised version
shaheed.haque at kdemail.net
Sun Nov 27 09:41:54 GMT 2005
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
- 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
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
> 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.
More information about the kde-core-devel