[Development] More on QDateTime / QTimeZone
John Layt
jlayt at kde.org
Thu Sep 12 21:06:03 CEST 2013
Hi,
Another QDateTime email. I'm still trying to get a fully working
reimplementation of QDateTime as well as the QTimeZone support in for 5.2, but
there's a couple of issues outstanding.
Storage format / Change of System Time Zone behaviour: My current changes on
Gerrit for storing as msecs uses local msecs and not epoch msecs. This allows
the originally set date and time to always stay constant and be returned even
if the time spec or system time zone changes during the life of the instance.
This is a long standing and documented behviour of QDateTime. Lars has
suggested that we instead use epoch msecs, which has the advantage of
simplifying a lot of code and solving a lot of corner-case bugs. There are
two disadvantages though. The first is it means creating a QDateTime becomes a
lot slower as we need to calculate the epoch offset up-front, instead of only
when/if needed. The second is it means that the behaviour of the local
date/time staying constant over time zone changes will no longer be true. It
would be up to the app to realise a time zone change has happened and to know
what to do with the datetimes as a result. We would need to implement a
QEvent for this. We would also need to decide if this means the offset is set
as at the time the QDateTime is created, or if the same offset is always used.
There's good arguments to both sides, but the behaviour change is not
something that has been fully thought out yet and so I don't think should be
done for 5.2.
Ambiguous times at the Daylight to Standard transition: it is probably
impossible to fix this bug using the standard C/Posix mktime call in an efficient
way. This is due to mktime having different behaviour and various bugs on all
3 main platforms (one way to consistently deal with the differences would be to
know the actual transition time, which is not provided). The only way to fix
this is to either write our own universal version of mktime using only calls
to localtime(), which might be possible but would likely be very inefficient, or
to use QTimeZone instead, which is probably not efficient enough yet and the
change of system time zone problem still needs solving first. None of this can
be done for 5.2 either.
For those interested the problems with mktime are:
* Windows assumes an ambiguous time to be the second occurrence / standard
time, but is at least consistent in doing so
* Mac assumes an ambiguous time to be the first occurrence / daylight time,
except after about 46 minutes when it assumes the second occurrence
* Linux assumes whatever occurrence resulted from the previous call to mktime,
i.e. effectively randomly
If we can settle these, I can get on with finishing this for 5.2:
* Choose either local msecs or epoch msecs, if epoch then that change can't be
done for 5.2
* Accept second occurrence won't be solved for 5.2, document behaviour as
undefined
* Integrate QTimeZone
Note that the QTimeZone code is unchanged since the last attempt for 5.1 so
should be a quick review.
John.
More information about the Development
mailing list