[Development] More on QDateTime / QTimeZone

[Knoll Lars]

On 9/12/13 9:06 PM, "John Layt" <jlayt at kde.org> wrote:

>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.  

We might be able to simply cache the time zone offset once and cache it.
Then it should be at the same speed.

>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.

Well, IMO that's in most cases what you'd want in any case. I can't see
how a date time specifying 5pm for a meeting should stay at 5pm when I fly
to finland...

>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.

A notification that the timezone (or DST) has changed would be good to
have in any case, but I don't think it needs to go into 5.2.

I am still in favour of changing QDT to store the value in UTC internally.
All we'd need to do to convert to local time is store the UTC offset
somewhere in QtCore (and update that value if the systems timezone
changes). I honestly think it would simplify a lot of code and make the
whole QDT behaviour much more consistent and easier to understand.

But yes, it would be a behavioural change that we'd need to properly
document.
>
>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.

Wouldn't the issues here be solved by storing all time values in UTC? In
any case, I don't believe this is a showstopper for 5.2.
>
>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

These are corner cases (as the OSes don't really solve them as well
apparently). I'd not worry too much about this for 5.2. If we get this
settled in 5.3 it's good enough.

Cheers,
Lars

>
>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
>Development at qt-project.org
>http://lists.qt-project.org/mailman/listinfo/development