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 documented: The range of valid dates taking DST into account is 1970-01-01 to the present, and rules are in place for handling DST correctly until 2037-12-31, but these could change. For dates falling outside that range, QDateTime makes a \e{best guess} using the rules for year 1970 or 2037, but we can't guarantee accuracy. This means QDateTime doesn't take into account changes in a time zone before 1970, even if the system's time zone database provides that information. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest