[Development] More on QDateTime / QTimeZone

[John Layt]

On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote:
> On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars <Lars.Knoll at digia.com> wrote:
> > We might be able to simply cache the time zone offset once and cache it.
> > Then it should be at the same speed.
> 
> This would also probably provide hidden wins in various places, making
> changes like b9ef4a9c3047228ec007ac81ff0a304f8cc274b7 in qtbase
> unnecessary. I'd like to see this for that reason :)

Well, that patch is taking advantage of the fact that creating a LocalTime is 
currently cheap, as is calling setTimeZone, neither of those steps currently 
require a conversion to UTC.  As explained in my reply to Lars with any change 
in storage you would always have to call mktime in the creation, so you 
immediately lose the speed-up from your patch.  There's probably a lot of 
places this will happen in Qt, not to mention other people's code.  There's no 
such thing as a free lunch :-)

The real problem is that the file code uses LocalTime internally when it should 
use UTC and only convert to LocalTime as the last step in the public api.  My 
understanding is Unix stores file times as time_t, and Windows as a FILETIME 
which is nsecs since 1601, both are UTC, so at the moment there is already a 
conversion from UTC to LocalTime required to create the LocalTime.  Creating 
and passing them around internally as UTC could be a big saving, however I 
suspect that would take a large change to achieve.

John.