[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