> From: Development <development-boun...@qt-project.org> On Behalf Of > Thiago Macieira > > On Tuesday, 9 April 2019 05:11:03 PDT Pouya Shahinfar wrote: > > You open a project which is developed by someone else, and he/she used > > QDateTime for holding time and date. The problem here is you as a > > newcomer to project do not know the value in the class is based on UTC > > or local time, etc. if there was a class like QLocalDateTime, the code > > was more maintainable. > > Why is the code unmaintainable or unreadable just because the information > is not in the class name? The information *is* there, held inside the object. > You can ask it (timeSpec(), offsetFromUtc() and timeZone()) what it is. > > So what is the problem?
We fell into the same QDateTime trap recently. The documentation on QDateTime is perhaps a bit too obscure and/or does not sufficiently highlight possible pitfalls? It might be good to highlight, for instance, that MSecsSinceEpoch is not share-able between users in different timezones unless QDateTime is instantiated with a timespec of Qt::UTC (which is not the default). The defaults (local time w. timezone conversion) are perhaps more likely to lead to error than the plain C time since epoch with no hours being added/subtracted. Mark _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
