Important: Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

QDateTime::fromString() returns invalid Datetime



  • Hello,

    I'm using QDateTime::fromString() and I've seen that in some cases the function returns an invalid DateTime for an unknown reason. Is this a bug? I'm using Qt5.15.2 under linux
    To evaluate the content of the variable, I used the debugger directly

    #include <QDateTime>
    
    int main(int argc, char *argv[])
    {
    	auto dt0 = QDateTime::fromString("2016-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz"); // valid
    	auto dt1 = QDateTime::fromString("2017-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz"); // invalid
    	auto dt2 = QDateTime::fromString("2018-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz"); // valid
    	auto dt3 = QDateTime::fromString("2019-03-27T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz"); // valid
    
    	return 0;
    }
    
    

  • Lifetime Qt Champion

    Because 2017-03-26T02:14:34.000 simply does not exists in europe.



  • @Christian-Ehrlicher Thank you for your response. But if this date is UTC it is valid or not?


  • Lifetime Qt Champion

    @Wuzi said in QDateTime::fromString() returns invalid Datetime:

    But if this date is UTC it is valid or not?

    But where do you pass this information? QDateTime::fromString() is using the current locale. Use QLocale::toDateTime() instead



  • It was just in general. How can I use toDateTime() to parse UTC time?
    I tried, but with no success:

    int main(int argc, char *argv[])
    {
    	QLocale l = QLocale(QLocale::Language::AnyLanguage, QLocale::Territory::World);
    	auto dt0 = l.toDateTime("2016-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz");
    	auto dt1 = l.toDateTime("2017-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz");
    	auto dt2 = l.toDateTime("2018-03-26T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz");
    	auto dt3 = l.toDateTime("2019-03-27T02:14:34.000", "yyyy-MM-ddThh:mm:ss.zzz");
    
    	return 0;
    }
    

    One possible solution which worked, was adding UTC to the string and the "t" format.

    #include <QDateTime>
    
    int main(int argc, char *argv[])
    {
    	auto dt0 = QDateTime::fromString("2016-03-26T02:14:34.000 UTC", "yyyy-MM-ddThh:mm:ss.zzz t");
    	auto dt1 = QDateTime::fromString("2017-03-26T02:14:34.000 UTC", "yyyy-MM-ddThh:mm:ss.zzz t");
    	auto dt2 = QDateTime::fromString("2018-03-26T02:14:34.000 UTC", "yyyy-MM-ddThh:mm:ss.zzz t");
    	auto dt3 = QDateTime::fromString("2019-03-27T02:14:34.000 UTC", "yyyy-MM-ddThh:mm:ss.zzz t");
    
    	return 0;
    }
    


  • Or let Qt parse the date as local and the tell the object to consider it UTC:

    qDebug() << QTimeZone::systemTimeZoneId();
    
    QDateTime dt = QDateTime::fromString("2016-03-26T02:14:34.000", Qt::ISODateWithMs);
    qDebug() << dt << dt.isValid();  // << Local time
    dt.setTimeSpec(Qt::UTC);
    qDebug() << dt << dt.isValid(); // << UTC, note time is not adjusted
    
    dt = QDateTime::fromString("2017-03-26T02:14:34.000", Qt::ISODateWithMs);
    qDebug() << dt << dt.isValid();
    dt.setTimeSpec(Qt::UTC);
    qDebug() << dt << dt.isValid();
    

    Output for my local time (UTC+10 no DST at all)

    "Australia/Brisbane"
    QDateTime(2016-03-26 02:14:34.000 AEST Qt::LocalTime) true
    QDateTime(2016-03-26 02:14:34.000 UTC Qt::UTC) true
    QDateTime(2017-03-26 02:14:34.000 AEST Qt::LocalTime) true
    QDateTime(2017-03-26 02:14:34.000 UTC Qt::UTC) true
    

    and in Europe (UTC+1 and DST)

    "Europe/Paris"
    QDateTime(2016-03-26 02:14:34.000 CET Qt::LocalTime) true
    QDateTime(2016-03-26 02:14:34.000 UTC Qt::UTC) true
    QDateTime(Invalid) false
    QDateTime(2017-03-26 02:14:34.000 UTC Qt::UTC) true
    

  • Moderators

    @ChrisW67 said in QDateTime::fromString() returns invalid Datetime:

    Or let Qt parse the date as local and the tell the object to consider it UTC:

    Well, no. The date is still invalid - it doesn't (always) exist in "local time" no matter whether you force it after that.
    The only correct solution is to provide the timezone information in the string, which is why ISO dates also allow it (and UTC is so prevalent that it has the shortest of formats - notice the traling 'Z'):

    QDateTime date = QDateTime::fromString("2017-03-26T02:14:34.000Z", Qt::ISODateWithMs);
    


  • @kshegunov said in QDateTime::fromString() returns invalid Datetime:

    Well, no. The date is still invalid - it doesn't (always) exist in "local time" no matter whether you force it after that.

    You are correct that some strings representing a date/time are always invalid in some time zones, and not in others. My observation relates to the way QDateTime behaves, not the way time zones behave.

    If you look at my example for Paris you will see the 2017 date is initially parsed, loaded and treated as Invalid (correctly). However, telling the QDateTime object containing the invalid time for Paris that it actually holds a UTC date/time generates the expected, valid result. The date/time components have been retained and the Invalid state is determined in light of the TimeSpec in use (LocalTime vs UTC). As the documentation for QDateTime::setTimeSpec() changing this results in a different point in time (in this case a valid one).

    Note, that this is distinctly not the same as converting the same point in time time between time zones. Attempting to determine the corresponding UTC time for an Invalid Paris time, in this case by adjusting by an undefined 1 or 2 hours, should also be expected to be Invalid or exhibit undefined behaviour. Interestingly, Qt loaded the original date with an offsetFromUtc() == 0 (there being no valid offset corresponding to the date string in Paris) and behaves as such when asked for toUTC().

    I work in aviation where everything is UTC/Zulu time by default, and local time by exception, and I agree with you that unambiguous date/time representations are important. Appending "Z" or "+00:00" to incoming unqualified date strings is an option, but having a source that issues unambiguous data from the start is definitely preferable.



  • @ChrisW67 said in QDateTime::fromString() returns invalid Datetime:

    I work in aviation where everything is UTC/Zulu time by default

    Hallelujah! I too have worked where multiple timezones are involved, and it's a pain. Why, oh why, can't the whole world agree to just use UTC everywhere, no time zones, it would make programs (and appointments) so much easier....?



  • Ok thank you. So I will add the trailing Z to the string so that it is correct. Thank you all!



  • @JonB said in QDateTime::fromString() returns invalid Datetime:

    Hallelujah! I too have worked where multiple timezones are involved, and it's a pain.

    It is not all roses though :( Times for passenger schedules are local, flight plans are all Zulu. In aviation runway lengths and widths are in metres, altitudes in feet, sometimes metres, referenced to the actual barometric pressure at the aerodrome or in the area (in hectopascals or inches of Mercury), or a flight level (hundreds of feet) relative to a standard pressure depending on the region and height at which you are flying. Airspeed is in knots or a Mach number, distances in nautical miles. Bearings are in degrees, typically magnetic, but North is sometimes 0 sometimes 360. Aircraft weight is given in pounds or kilogrammes/tonnes, engine thrust in pound force or newtons, fuel in pound, litres, kg/tonnes and sometime even gallons (US or imperial). Terrain elevation might be given in feet or metres, but safety clearances (above or laterally) are in metres for terminal procedure design and feet in general elsewhere. Temperatures are in Celsius mostly, Fahrenheit sometimes. Weather reports at aerodromes give horizontal visibility in kilometres or statute miles. Latitudes/longitudes are sometimes presented in decimal, sometimes sexagesimal with variable precision/spacing/formatting. Aircraft structures are variously metric or imperial.



  • @ChrisW67
    OMG!!

    But my desire is that there is no "local time" anywhere, just everyone uses UTC always. Miles simpler....

    The crazy things about all those different units you mention is that --- once they have to proper code to measure/convert --- computers really don't have any problems dealing with them all effortlessly. Which is why pilots' days --- like many other professions --- are numbered... :)


  • Moderators

    @ChrisW67 said in QDateTime::fromString() returns invalid Datetime:

    You are correct that some strings representing a date/time are always invalid in some time zones, and not in others. My observation relates to the way QDateTime behaves, not the way time zones behave.

    It's worse than that. Some points are ambiguous in local time with DST in effect, and some plainly don't exist at all. Not to mention you're suggesting a hidden use case for QDateTime, which may or may not work due to an implementation detail. Sorry, it simply is an incorrect solution.


Log in to reply