[Development] QTimeScheme for Qt - 5.0 or 5.1?

Thiago Macieira thiago.macieira at intel.com
Fri Jan 27 12:16:15 CET 2012


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

So I guess we've got a very bad class name. Is that a time zone? If so, why 
not call it QTimeZone?

> 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 much prefer value-type classes, implicitly shared.

> 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). But the Olsen identifier would be nice too, 
if we have it. A custom timezone would include just the offset.

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

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

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?

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


More information about the Development mailing list