KDateTime: next iteration

[Nicolas Goutte]

On Tuesday 29 November 2005 11:46, Nicolas Goutte wrote:
> On Tuesday 29 November 2005 11:11, Thiago Macieira wrote:
> > Nicolas Goutte wrote:
> > >On Monday 28 November 2005 21:50, Thiago Macieira wrote:
(...)
(> > That's not what I meant. From the discussion, it seemed we're talking
> > about backends to store information. We have only 2 (or 3, with the
> > "unknown" type) backends.
>
> We have 5 cases:
> - UTC (compatiblity to QDateTime)
> - local time (system's timezoine, compatiblity to QDateTime)
> - named timezones (that is why the KDateTime class was created for.)
> - time offset (needed as modern time specification like RFC 2822 or ISO
> 8601 have only time offsets, no named timezones).
> - unknown (for cases where we cannot define the timezone)

Forget this. That is not how it is implemented internally. Sorry!

>
(...)