QDateTime ASSERTS if constructing a new object with a invalid date/time, but a valid timezone

On macOS, create a QDateTime object like this:  

QDateTime(QDate(), QTime(), QTimeZone::systemTimeZone());

 
In debug mode, it'll assert here: qtimezoneprivate.cpp line 329. 

This is because the QMacTimeZonePrivate::previousTransition function returns a invalid QTimeZonePrivate::Data structure when "forLocalMSecs" is equal to zero (which it will be when the date and time portion of the QDateTime are invalid). 

The output on assert is this 

[wopr:~/Desktop/datetime]$ export DYLD_IMAGE_SUFFIX=_debug
[wopr:~/Desktop/datetime]$ ./datetime
ASSERT: "forLocalMSecs < 0 || forLocalMSecs >= tran.atMSecsSinceEpoch +
tran.offsetFromUtc * 1000" in file tools/qtimezoneprivate.cpp, line 332
Abort trap: 6

To reproduce it requires debug version of the frameworks? In QtCreator, check-off the "Use debug version of the frameworks".

The function where the assert happens, you can see that it easily handles the fallback situation where the values are invalid. The assert is needless and roadblocks a developers who  actual do run into situations were the QDateTime object is instantiated with invalid
date/times but a valid timezone. Instead of an assert, use qWarning(), or even qCritical() if you must. There is no need to force an application abort in this case.