[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