Re: [Interest] QDateTime uses different time zone offset prior to UNIX epoch?
Ah, I read your response in the forum differently. Thank you. > On Sep 21, 2019, at 2:18 AM, Christian Ehrlicher wrote: > > Am 21.09.2019 um 00:12 schrieb Thiago Macieira: >>> On Friday, 20 September 2019 14:20:40 PDT Patrick Stinson wrote: >>> QDateTime initializes with a different time zone offset when passed a QDate >>> before versus after Jan 1 1970. The following line says it all: >>> >>> QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10, >>> 14)).offsetFromUtc() >>> >>> It seems to me that the offsets for these two QDateTime objects should be >>> equal. Otherwise, this makes initializing and storing dates difficult. >>> >>> I assume this is intentional. What is the rationale for this design >>> decision? Is there a workaround? >> Your test is not reliable. It works for less than half the planet and for >> just >> over half the year. >> >> Anyway, there's no workaround. This is done because the timezone databases >> are >> inaccurate before 1970. So we just return each timezone's standard time, not >> accounting for DST. > This is what I told him at the forum - mktime() on windows simply > returns the wrong dst value for 1969 (but linux does in this case). > > Christian > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Assertions from QQuickTableView::forceLayout()
Il 21/09/19 05:40, Patrick Stinson ha scritto: In many cases this assertion happens when TableView.rows is out of sync with model.rowCount(), or TableView.columns is out of sync with model.columnCount(). The fact that these are out of sync at all seems to me to be a bug? Do you have a minimal testcase? (E.g. a minimal custom model that is shown in a TableView, and that causes the assert). That would be enough to open a bugreport. Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QDateTime uses different time zone offset prior to UNIX epoch?
Am 21.09.2019 um 00:12 schrieb Thiago Macieira: On Friday, 20 September 2019 14:20:40 PDT Patrick Stinson wrote: QDateTime initializes with a different time zone offset when passed a QDate before versus after Jan 1 1970. The following line says it all: QDateTime(QDate(1969, 10, 14)).offsetFromUtc() != QDateTime(QDate(1970, 10, 14)).offsetFromUtc() It seems to me that the offsets for these two QDateTime objects should be equal. Otherwise, this makes initializing and storing dates difficult. I assume this is intentional. What is the rationale for this design decision? Is there a workaround? Your test is not reliable. It works for less than half the planet and for just over half the year. Anyway, there's no workaround. This is done because the timezone databases are inaccurate before 1970. So we just return each timezone's standard time, not accounting for DST. This is what I told him at the forum - mktime() on windows simply returns the wrong dst value for 1969 (but linux does in this case). Christian ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
