Important: Please read the Qt Code of Conduct -

[SOLVED] QDateTime is invalid, why?

  • Hello,

    The code follows:
    const QDateTime yearStart(QDate(QDate::currentDate().year(), 1, 1));
    Q_ASSERT(yearStart.isValid()); // Fails!

    const QDateTime now(QDateTime::currentDateTime());
    Q_ASSERT(now.isValid()); // Succeeds!

    The question is, why the first QDateTime is considered to be invalid? This is on Qt 5.2.1 on Windows with mingw.

  • A small note:

    const QDateTime yearStart(QDate(QDate::currentDate().year(), 1, 1), QTime(1,0,0));
    const QDateTime d = yearStart.addSecs(-3600);
    const QDateTime d2 = yearStart.addSecs(-1800);

    yearStart is valid here, and it equals "Wed Jan 1 01:00:00 2014".
    If I try to make QTime lesser than 1 hour, then it is invalid.

    d equals "Tue Dec 31 23:00:00 2013".
    d2 equals "Tue Dec 31 23:30:00 2013".

    I don't understand what happens here :(

  • Update 1: it depends on the time zone the computer is in. In "Europe/Moscow", the problem exists. In "Etc/GMT" (i.e., UTC), it doesn't.
    Update 2: if I switch off the option "Automatically adjust clock for daylight saving changes", the problem goes away.
    Update 3: if I set time to the future (Oct 27, 2014), the problem persists, but it's impossible to switch off the option, because it is absent now.
    Update 4: if I switch off the option, THEN set time to the future, the problem goes away too.

    Can anyone confirm this behavior?
    Could it be due to recent time zone update from Microsoft?..
    If the problem is not solved, this could lead to incorrect operation of Qt apps in russian time zones...

  • Problem is made somewhat clearer with the help of time zone information editor:

    It shows that my computer has the following settings: enable daylight saving time from the first Wednesday of January at 0:00:00 to the last Sunday of October at 02:00:00.

    It seems that's the way Microsoft has issued its russian time zones fix: assume they are in daylight saving time from the beginning of the year. But then the date 01.01.2014 0:00:00 is indeed invalid in my time zone (i.e. new year begins at 1 o'clock).

    The point of this whole story is that I should have used UTC times only, and local time maybe only for display purposes.

  • On the 2nd thought, I think that it's the time zone update by Microsoft which caused the bug. Because 01.01.2014 0:00:00 was a perfectly vaild datetime in reality, even in Moscow :-) But Qt now considers it to be invalid because it relies on time zone data provided by Microsoft.

Log in to reply