2

Holy f-ing hell!
Why do the small things have such fucked up corner cases?
This is very likely a giant bug with Qt, but how does this even happen?
I am using Qt with QML and sending data to a database on the backend. I call functions in QML from a Date JS object (property actually, but it calls functions) to set the date as a QDate. This is stored in the database as yyyy/MM/dd. This is fine. When I read the date out I convert it back from string to QDate and send this object to QML. Which then converts this to a Date object in JS in QML.

But at the point where it converts from a QDate to a Date object it loses an entire day. Seriously? You didn't gain a day going from Date -> QDate, but you lose a day going from QDate -> Date?

How long has QML and Qt been around? At least 5 to 10 years. How has this bug lasted this long? I don't want to do a bug report. I will, but I don't want to .

Comments
  • 5
    Timezone differences at play?
  • 2
    @asgs Same thought as I was going through it.
  • 2
    Locale issues detected
  • 1
    It loses data in the conversion as QDate does not have time included.

    If this gives any clues:

    qml: Mon Feb 21 08:33:22 2022 GMT-0700

    setDate() QDate("2022-02-21")

    date() QDate("2022-02-21")

    qml: Sun Feb 20 17:00:00 2022 GMT-0700

    The code that prints this (js):

    let date = new Date()

    console.log(date)

    dobj.setDate(date)

    let ndate = dobj.date()

    console.log(ndate)

    C++:

    Q_INVOKABLE QDate date(){

    qDebug() << "date()" << m_date;

    return m_date;

    }

    Q_INVOKABLE void setDate(QDate ndate){

    qDebug() << "setDate()" << ndate;

    m_date = ndate;

    }
  • 1
    @gosubinit very likely. Not going to mess with this at all. Just going to convert to string and send that to database to begin with. So I only pass strings.
  • 2
    Okay QDateTime object behaves as I want. Don't use a lossy data format is what I am getting from this.
Add Comment