[Development] QTimeScheme for Qt - 5.0 or 5.1?

[lorn.potter at nokia.com]

On 28/01/2012, at 1:03 AM, ext 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?
>  
> > > 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?

On *nix, since the timezone database is part of the system/distribution, the db doesn't need to be in Qt, although it _could_ be.
The conversion was only best name/place match, but you could get valid windows timezone data in windows using "Australia/Brisbane" without
cygwin, and vice versa, "E. Australia Standard Time" on linux/mac would get Australia/Brisbane.




>  
> > 
> > > > I didn't get what QDataStream has to do with anything. Are you
> > > > asking how QDateTime should include the information about the
> > > > timezone it's associated
> > > > with? One way is to include the UTC offset in seconds or minutes
> > > > (minutes allows us to keep it with 16 bits).
> > > 
> > > That probably wouldn't work for historical datetimes, would it?
> > 
> > If you mean "before 1970", they should simply use an undeterminate timezone.
>  
> I don't think it's that simple. Maybe Lorn knows.

The database does extend past beyond 1970. Even if not is not exactly accurate, it's better than 'undetermined'. Heck, even up to date db is not exact as places can change their time data on a whim.



>  
> > > > But the Olsen identifier would be nice
> > > > too, if we have it. A custom timezone would include just the offset.
> > > 
> > > What is a custom timezone? If we have the Windows timezone identifier
> > > should we include that too?
> > 
> > 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?
>  
> > > 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.

I have attached a patch to the QTBUG-71
https://bugreports.qt-project.org/secure/attachment/27114/tz2.diff

No guarantees it will still work, and the s60 code can be removed (it never totally worked anyway, as all devices limited the number of timezones available, and all had different number of timezones, not to mention the db was compiled and the tz server never returned all the info needed for this to work...) 

>  
> Thanks,
>  
> -- 
> Stephen Kelly <stephen.kelly at kdab.com> | Software Engineer
> KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
> www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-Independent Software Solutions
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

Lorn Potter
Senior Software Engineer, Core Enablers/QtSensors