[Development] QDateTime is missing shared null optimization

[Thiago Macieira]

On Sunday 02 August 2015 01:24:50 John Layt wrote:
> [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

That was actually -4713 to 4207 range. I calculated it so that we keep the 
same origin point for the short msecs as the one in d->msecs.

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

No, I didn't. We could keep only the case of ValidDateTime, with the case of 
null date & null time represented by a null pointer.

How often do people construct a QDateTime containing only a QDate as a 
stepping stone to a full QDateTime? Note that the QDateTime constructor 
containing a QDate sets a valid time; you can only get valid date and null 
time if you use the constructor with QTime and pass an invalid time, so I'd 
advocate that you should suffer and allocate memory if you do that.

> Also OffsetFromUTC supports weird offsets that are not 15 minute
> intervals.

True, but there aren't any official timezones outside a quarter-hour boundary. 
So a 7-bit combined offset & timespec should be enough for most use-cases. If 
you need more, you'll get it, but will cause memory allocation.

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

If someone benchmarked how often QDateTime mallocs, it would be nice.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center