QDateTimeEdit has a timeSpec property.
This can be set to Qt::UTC or Qt::LocalTime.
The relevant type also has values Qt::OffsetFromUTC, which needs an accompanying int offset (in seconds), and Qt::TimeZone, which needs an accompanying QTimeZone object.
One cannot set the timeSpec property to either of these, as doing so would invalidate all the date/time members (stored as QVariant so they can be QDate, QTime or QDateTime) of QDateTimeEdit (since it'd try to set their spec without supplying needed information).
(This may indicate that QDateTimeEdit is older than these Qt::TimeSpec values.)

This matches the old QDateTime::toTimeSpec() method, which has the same limitations; calls to it should be replaced by QDateTime's newer toUTC(), toLocalTime(), toOffsetFromUtc(offset) and toTimeZone(zone) methods. QDateTimeEdit could support similar methods to set its spec; however, setting a time-spec attribute is not a sensible option in general (though reading one is, in moderation).
Note that the timeSpec attribute is redundant with the time-spec of the date/time held as the QDateTimeEdit's current value.

In the long term, we need to kill the Qt::TimeSpec, as it's an anti-helpful abstraction.

Resolving this would require significant API changes to QDateTimeEdit (e.g. removal of the time-spec property, at least), so can only be done around a major version transition.