On Friday, 27 de January de 2012 12.48.13, Stephen Kelly wrote: > > > It might also make sense to use QSharedPointer<QTimeScheme> in the APIs. > > > > Before you argue for QSharedPointer of QTimeScheme, you need to tell us > > why > > pointers are necessary. Are people supposed to new them? > > I was imagining perhaps some sort of registry that users would maintain and > new them, yes.
Those requirements don't seem to require pointers.
> > I much prefer value-type classes, implicitly shared.
>
> Would that also mean 'not extendible'?
"extensible"
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.
If you're going to make them objects, please derive from QObject.
> 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.
> > 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.
> > 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.
> > Which cases wouldn't QDateTime want to include the timezone information?
>
> I don't know. Possibly when communicating with systems which don't know how
> to consume it. Maybe the revision feature of QDataStream is enough for that
> anyway.
We need to change the version number anyway because we need to include more
information.
> > > I think something like this abstraction should go into Qt 5.0, but I
> > > would like to get other opinions too. Do you think something like this
> > > can be added in 5.1 just as well?
> >
> > I don't see why not. What would be source incompatible?
>
> That might depend on whether the timezone class is used as a pointer or not,
> and what comes built in with Qt, and whether and if it's an extendible
> system.
I don't see why pointer-vs-value type changes anything. If it can be done with
QSharedPointer, it can be done with a value type wrapper.
The class should come built-in and it should support a few timezones out-of-
the-box. I am not saying we should bundle the Olson DB, but we should use it
if it's present. We need more info on Windows.
> If local time and offset from UTC are built into Qt, there may indeed be no
> problem.
They already are.
> 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.
No one can set a timezone on a QDateTime before timezone support is added. So
I don't see what behaviour incompatible changes there might be.
--
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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
