[Development] QTimeScheme for Qt - 5.0 or 5.1?

Thiago Macieira thiago.macieira at intel.com
Fri Jan 27 18:36:05 CET 2012


On Friday, 27 de January de 2012 16.03.51, Stephen Kelly wrote:
> On Friday, January 27, 2012 13:30:35 Thiago Macieira wrote:
> > Correct. What do we need extending them with? The only virtuals you left
> > in
> > the API were stream (which I didn't get) and utcOffset, which doesn't seem
> > to need to be a virtual.
> 
> Different timezones (and countries) have daylight savings time at different
> times of the year (or different days from year to year). Different
> implementations of utcOffset would take account of that. So there's a
> dependence on both the timezone and the datetime object.
> 
> What do you propose?

I see. You're proposing a public class for the time zone *engine* (and that 
should be the class name). I don't think that's necessary, though.

There are likely only two engines: Olson and Windows. And one of them is 
platform-specific.

> > > And therefore the olson db and
> > > windows registry timezone information code would need to be in QtCore?
> > 
> > See Lorn's email. I don't know why we'd need to keep them in QtCore.
> 
> Lorn's email said he used the windows and olsondb info. If not in QtCore,
> where would they go?

The DBs themselves or the engine? The engines should be in QtCore.

Is there any system outside of Windows that doesn't have the Olson DB?

> > If you mean "before 1970", they should simply use an undeterminate
> > timezone.
>
> I don't think it's that simple. Maybe Lorn knows.

The Olson DB contains attempts at data before 1970, but it's inaccurate. We 
can keep the information with the serialisation, but being wrong is not a big 
deal.

> > I was thinking of two cases: 1) a QDateTime with an UTC offset set,
> > instead
> > of a proper timezone or 2) when $TZ or /etc/localtime point to a timezone
> > which we can't find in the DB.
> 
> If we just drop such information and use utc offset when storing it, then
> 'custom timezones' are useless anyway, right?

We don't want to store just the offset if we know more. Timezones often change 
around during the year...

> > > But yes, now I think about it, adding timezone information is probably
> > > not source incompatible. I do still wonder about behaviour
> > > compatibility, but that's probably solvable too.
> 
> Sorry, I meant to write 'probably source compatible'.
> 
> Anyway, I think Lorn needs to give more input and maybe his patch.

Yes, we need that too :-)

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
     Intel Sweden AB - Registration Number: 556189-6027
     Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120127/619d9f18/attachment.sig>


More information about the Development mailing list