On Thursday 12 Sep 2013 22:24:40 Robin Burchell wrote: > On Thu, Sep 12, 2013 at 9:24 PM, Knoll Lars <[email protected]> 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. _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
