[Interest] QDateTime uses different time zone offset prior to UNIX epoch?

Thiago Macieira thiago.macieira at intel.com
Sat Sep 21 00:12:39 CEST 2019


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






More information about the Interest mailing list