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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
