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