[Development] QTimeScheme for Qt - 5.0 or 5.1?

[Stephen Kelly]

On Friday, January 27, 2012 12:16:15 Thiago Macieira wrote:
> On Thursday, 26 de January de 2012 23.43.45, Stephen Kelly wrote:
> > Some of the API, eg 'void setUtcOffset(int seconds);' could be
> > implemented by creating a new QTimeScheme properly configured with a
> > UTC offset, but I took it out anyway rather than attempting to show a
> > port in the patch.
> What is a "time scheme"?
> 
> This seems completely unrelated: http://en.wikipedia.org/wiki/Time_scheme
> > That would be a source incompatible change if it happened in Qt 5.1. I'm
> > also unsure about mapping cleanly from the Qt::TimeSpec enum to some
> > class like QTimeScheme (I named it that instead of QTimeZone because
> > utc offsets are not time zones).
> 
> Keep it QTimeZone because people understand what it is.
> 
> So I guess we've got a very bad class name. Is that a time zone? If so, why
> not call it QTimeZone?

Fair enough. I'm not attached to the name.

> 
> > 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.

> 
> I much prefer value-type classes, implicitly shared.

Would that also mean 'not extendible'? And therefore the olson db and windows 
registry timezone information code would need to be in QtCore?

> 
> > What I would mostly like to get feedback on though is the impact on the
> > QDateTime API and behaviour, and how it is put through QDataStream etc.
> > I'm not sure if there is any particular way (historical) timezone
> > information should be transmitted over the wire (if at all).
> 
> A QDateTime should be associated with a timezone.
> 
> 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?

> 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?

> > If it should not be handled at all in some cases of streaming a
> > QDateTime, but it should be handled in others (which I think is the
> > case - we don't want to lose this information in most cases), the
> > to-be-streamed QDateTime would have to have its timezone information
> > stripped in the former case.
> 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.

> 
> Qt::TimeSpec is just an enum with a few known timezones: local and UTC.
> 
> > 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.

If local time and offset from UTC are built into Qt, there may indeed be no 
problem.

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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120127/2659957f/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120127/2659957f/attachment.sig>