Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. Qt Development
  3. General and Desktop
  4. QDateTime::fromString() returns invalid Datetime
Forum Updated to NodeBB v4.3 + New Features

QDateTime::fromString() returns invalid Datetime

Scheduled Pinned Locked Moved Solved General and Desktop
23 Posts 6 Posters 3.7k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • C ChrisW67

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

    JonBJ Offline
    JonBJ Offline
    JonB
    wrote on last edited by JonB
    #9

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

    C 1 Reply Last reply
    0
    • W Offline
      W Offline
      Wuzi
      wrote on last edited by
      #10

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

      1 Reply Last reply
      0
      • JonBJ JonB

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

        C Offline
        C Offline
        ChrisW67
        wrote on last edited by
        #11

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

        JonBJ 1 Reply Last reply
        0
        • C ChrisW67

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

          JonBJ Offline
          JonBJ Offline
          JonB
          wrote on last edited by
          #12

          @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... :)

          1 Reply Last reply
          0
          • C ChrisW67

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

            kshegunovK Offline
            kshegunovK Offline
            kshegunov
            Moderators
            wrote on last edited by
            #13

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

            Read and abide by the Qt Code of Conduct

            1 Reply Last reply
            0
            • C Offline
              C Offline
              Christian M.
              wrote on last edited by Christian M.
              #14
              This post is deleted!
              JonBJ 1 Reply Last reply
              0
              • C Christian M.

                This post is deleted!

                JonBJ Offline
                JonBJ Offline
                JonB
                wrote on last edited by JonB
                #15

                @Christian-M
                Hello and welcome.

                I do not understand. The whole point is that is that from 02:00 to 02:59 on that day there IS no "valid time". It does not exist. In local time, which is what you are asking about. At best it is ambiguous: does 02:30 represent 30 minutes after the clocks changed from 02:00 or 30 minutes before they changed to 03:00? So I don't know what you mean by "To get a valid QDateTime for example in UTC" when the local time is simply not valid. If you want to treat 02:30 as a UTC time that is fine, but is quite a different time from local time.

                1 Reply Last reply
                0
                • C Offline
                  C Offline
                  Christian M.
                  wrote on last edited by Christian M.
                  #16
                  This post is deleted!
                  JonBJ 1 Reply Last reply
                  0
                  • C Christian M.

                    This post is deleted!

                    JonBJ Offline
                    JonBJ Offline
                    JonB
                    wrote on last edited by JonB
                    #17

                    @Christian-M
                    OK, so the only correct way to do this is: convert from foreign TZ (where 02:00--03:00 is valid) to UTC, convert from UTC to your local TZ (no ambiguity, a given UTC only maps to one local TZ time). It never was correct to even try to interpret that foreign TZ time as a local time. You might as well interpret that foreign time as though it were UTC, since you don't know anyway, then at least it won't cause an error.

                    QDateTime QDateTime::fromString(const QString &string, const QString &format, const QTimeZone &timeZone);

                    Indeed! Can one not achieve this by either adding some TZ information to the string or is void QDateTime::setTimeZone(const QTimeZone &toZone) just what this is for? I might have a play later if I have some time....

                    P.S.
                    I see that @Christian-Ehrlicher said earlier

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

                    Maybe that will allow conversion from a foreign local time?

                    C 1 Reply Last reply
                    0
                    • JonBJ JonB

                      @Christian-M
                      OK, so the only correct way to do this is: convert from foreign TZ (where 02:00--03:00 is valid) to UTC, convert from UTC to your local TZ (no ambiguity, a given UTC only maps to one local TZ time). It never was correct to even try to interpret that foreign TZ time as a local time. You might as well interpret that foreign time as though it were UTC, since you don't know anyway, then at least it won't cause an error.

                      QDateTime QDateTime::fromString(const QString &string, const QString &format, const QTimeZone &timeZone);

                      Indeed! Can one not achieve this by either adding some TZ information to the string or is void QDateTime::setTimeZone(const QTimeZone &toZone) just what this is for? I might have a play later if I have some time....

                      P.S.
                      I see that @Christian-Ehrlicher said earlier

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

                      Maybe that will allow conversion from a foreign local time?

                      C Offline
                      C Offline
                      Christian M.
                      wrote on last edited by Christian M.
                      #18
                      This post is deleted!
                      JonBJ 1 Reply Last reply
                      0
                      • C Christian M.

                        This post is deleted!

                        JonBJ Offline
                        JonBJ Offline
                        JonB
                        wrote on last edited by JonB
                        #19

                        @Christian-M
                        Firstly, your post has literally crossed with my adding a P.S. to my reply above.

                        foreingTz.setTimeZone(QTimeZone(QByteArray("UTC+3")));

                        Are you sure this approach is correct (I don't think so)? Ignoring for the moment that you may know the foreign timezone name but not its UTC offset. Let's say this foreign TZ has its own daylight savings rules, and let's say that this foreign local time does (or does not, you don't know) lie in its DST. Then, correct me if I am wrong, I cannot see how from UTC+3 datetime code could possibly know whether DST is or is not in effect on the stated time. In effect, you need to know whether to pass, say, UTC+3 vs UTC+4 for that foreign local time at its different times of year, and you do not know that. In which case, it cannot convert correctly.....???

                        [P.S. I assume your input string does not itself come with any UTC+... suffix on it. Obviously if it does then the whole thing is trivial, since one can get to UTC from that and then UTC to your local. I assume you mean the time string has no UTC information on it, just that you know it comes from e.g. Europe in local time and are wanting to convert to Melbourne local time.]

                        C 1 Reply Last reply
                        0
                        • JonBJ JonB

                          @Christian-M
                          Firstly, your post has literally crossed with my adding a P.S. to my reply above.

                          foreingTz.setTimeZone(QTimeZone(QByteArray("UTC+3")));

                          Are you sure this approach is correct (I don't think so)? Ignoring for the moment that you may know the foreign timezone name but not its UTC offset. Let's say this foreign TZ has its own daylight savings rules, and let's say that this foreign local time does (or does not, you don't know) lie in its DST. Then, correct me if I am wrong, I cannot see how from UTC+3 datetime code could possibly know whether DST is or is not in effect on the stated time. In effect, you need to know whether to pass, say, UTC+3 vs UTC+4 for that foreign local time at its different times of year, and you do not know that. In which case, it cannot convert correctly.....???

                          [P.S. I assume your input string does not itself come with any UTC+... suffix on it. Obviously if it does then the whole thing is trivial, since one can get to UTC from that and then UTC to your local. I assume you mean the time string has no UTC information on it, just that you know it comes from e.g. Europe in local time and are wanting to convert to Melbourne local time.]

                          C Offline
                          C Offline
                          Christian M.
                          wrote on last edited by Christian M.
                          #20
                          This post is deleted!
                          JonBJ 1 Reply Last reply
                          0
                          • C Christian M.

                            This post is deleted!

                            JonBJ Offline
                            JonBJ Offline
                            JonB
                            wrote on last edited by JonB
                            #21

                            @Christian-M
                            Firstly, I mistook you for the OP, I see now you were a responder. I was trying to answer/help the OP. I am not the one who is confused! I have been working with cross-timezone code for decades! What I am trying to discover is how to do something in Qt with this, which I have not done.

                            My understanding of what the OP was asking is:

                            • He is in Australia/Melbourne, that is his local tz.
                            • He gets a datetime string to parse. It does not have a tz specification, e.g. something like "2017-03-26T02:14:34.000".
                            • He does know it represents a local time, and he does know which timezone it is from, but it is not his local timezone. And he does not know whether the foreign time lies in foreign DST or Standard time, he just knows the time is "correct" for a foreign local time. This is important.
                            • The question is what Qt code can he write to correctly parse that datetime from its "foreign" tz to a datetime in his local tz (or to UTC).

                            I do not see how your

                            QCalendar cal(QCalendar::System::Julian);
                            QDateTime ts = QDateTime::fromString("02/10/2022 02:00:00", "dd/MM/yyyy hh:mm:ss", cal); //valid
                            

                            can possibly address this. The fact that you use Julian calendar does not alter the problem. Since nowhere have you told it that the string comes from a foreign local time, it has no idea what this "02:00" time actually was in UTC.

                            Could you please show a worked example you claim which addresses this correctly? Let's say you are in Australia and you are given "02/10/2022 02:00:00" which you know to be in, say, UK time. But your code is not running in UK. Please show how you convert that to, say, UTC time in Qt. Thank you.

                            C 1 Reply Last reply
                            0
                            • JonBJ JonB

                              @Christian-M
                              Firstly, I mistook you for the OP, I see now you were a responder. I was trying to answer/help the OP. I am not the one who is confused! I have been working with cross-timezone code for decades! What I am trying to discover is how to do something in Qt with this, which I have not done.

                              My understanding of what the OP was asking is:

                              • He is in Australia/Melbourne, that is his local tz.
                              • He gets a datetime string to parse. It does not have a tz specification, e.g. something like "2017-03-26T02:14:34.000".
                              • He does know it represents a local time, and he does know which timezone it is from, but it is not his local timezone. And he does not know whether the foreign time lies in foreign DST or Standard time, he just knows the time is "correct" for a foreign local time. This is important.
                              • The question is what Qt code can he write to correctly parse that datetime from its "foreign" tz to a datetime in his local tz (or to UTC).

                              I do not see how your

                              QCalendar cal(QCalendar::System::Julian);
                              QDateTime ts = QDateTime::fromString("02/10/2022 02:00:00", "dd/MM/yyyy hh:mm:ss", cal); //valid
                              

                              can possibly address this. The fact that you use Julian calendar does not alter the problem. Since nowhere have you told it that the string comes from a foreign local time, it has no idea what this "02:00" time actually was in UTC.

                              Could you please show a worked example you claim which addresses this correctly? Let's say you are in Australia and you are given "02/10/2022 02:00:00" which you know to be in, say, UK time. But your code is not running in UK. Please show how you convert that to, say, UTC time in Qt. Thank you.

                              C Offline
                              C Offline
                              Christian M.
                              wrote on last edited by Christian M.
                              #22
                              This post is deleted!
                              JonBJ 1 Reply Last reply
                              0
                              • C Christian M.

                                This post is deleted!

                                JonBJ Offline
                                JonBJ Offline
                                JonB
                                wrote on last edited by JonB
                                #23

                                @Christian-M
                                Hi, it has taken me a day to get back to you.

                                Unfortunately I am on Qt 5.12 where there is no QCalendar, that was introduced at 5.14. So I cannot test your whole principle of a default Julian calendar and passing that to QDateTime::fromString(). So unless you know of an equivalent to your code for Qt <= 5.12 I cannot test anything.

                                What I can say is that at 5.12

                                    QDateTime foreingTz = QDateTime::fromString(datetime_foreign_with_no_timezone_spec);
                                    foreingTz.setTimeZone(QTimeZone(QByteArray(foreign_timezone)));
                                

                                does seem to work, where my objective is to treat datetime_foreign_with_no_timezone_spec as a local time in foreign_timezone. What it does is:

                                1. Initial fromString() treats datetime_foreign_with_no_timezone_spec as a local time in my local timezone.
                                2. Calling setTimeZone(foreign_timezone) on that does seem to alter the interpretation of the original datetime string as a local time in the foreign timezone (which is what I am trying to achieve).
                                1 Reply Last reply
                                0

                                • Login

                                • Login or register to search.
                                • First post
                                  Last post
                                0
                                • Categories
                                • Recent
                                • Tags
                                • Popular
                                • Users
                                • Groups
                                • Search
                                • Get Qt Extensions
                                • Unsolved