[Development] QTimeScheme for Qt - 5.0 or 5.1?

[Thiago Macieira]

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
-------------- 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/ca7f329d/attachment.sig>