[Development] QDateTime is missing shared null optimization

John Layt jlayt at kde.org
Sun Aug 2 02:24:50 CEST 2015

[Reply to list this time...]

This could work, as Qt::LocalTime / Qt::UTC / Qt::OffsetFromUtc don't
actually create or use QTimeZone for anything (at least not yet,
LocalTime may yet). I'm assuming dates outside the 1970-4207 year
range would still use the d_ptr implementation, as would anything
using Qt::TimeZone? Otherwise there would be issues with date input
fields that expect years up to 9999 to be valid. I'm also not sure if
you've taken the internal StatusFlag field into account as well as the
TimeSpec field, I'm not sure all that would fit properly into 64 bits.
Also OffsetFromUTC supports weird offsets that are not 15 minute

It would require a lot of shuffling code around, as a lot of code is
in the d_ptr, it would horribly complicate things and there's the
potential for interesting corner cases, like say adding enough years
to a date to push it from one implementation to another... Is the
complexity worth it?


More information about the Development mailing list