Ah, I read your response in the forum differently. Thank you.
> On Sep 21, 2019, at 2:18 AM, Christian Ehrlicher <[email protected]> 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 > [email protected] > https://lists.qt-project.org/listinfo/interest _______________________________________________ Interest mailing list [email protected] https://lists.qt-project.org/listinfo/interest
