I whole heartedly disagree. Everything should always be stored in UTC. Not GMT.
Why? Because dates, and particularly times, are not that simple. UTC does not observe Daylight Saving time, but local timezones sometimes do, and those saving time zones do not all kick in at the same time.
I think these classes would just encourage timezone anti-patterns.
Sent: Tuesday, April 09, 2019 at 8:11 AM
From: "Pouya Shahinfar" <pswi...@gmail.com>
To: development@qt-project.org
Subject: [Development] Adding more Datetime classes to Qt
From: "Pouya Shahinfar" <pswi...@gmail.com>
To: development@qt-project.org
Subject: [Development] Adding more Datetime classes to Qt
Although QDateTime has a full set of methods for working with date and times in Qt, It could lead to misunderstanding. How? Well when you are saving a date or time in this class you do not know the time is local time, UTC time or it is for a specific timezone. Therefore, maintaining the application becomes harder. Let's consider this scenario:
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.
Qt has an awesome set of classes but unfortunately when it comes to timing. the classes are really awkward. For instance, there is not a class for holding a time-span:
As far as I concern, It would be a good idea that Qt has the following class:
1. QTimeSpan -> for holding duration of time.
2. QInstant -> For holding an instant of time in UTC time (like Java)
3. QLocalDateTime -> For holding local datetime
4. QUTCDateTime -> For holding UTC datetime
5. QZonedDateTime -> For date and times which is in a specific timezone.
_______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
