Write a blog post about 6.2's fixing of zone info after 2037 and before 1970

In 6.3, QDateTime and QTimeZone stopped artificially ignoring available knowledge of time-zone changes before 1970 and after 2037. The former was formerly done because MS-Win's time_t functions don't support times before 1970, the latter because 32-bit time_t runs out early the next year.

The 1970 bound implied extrapolating back, to times before 1970, zone information that was only valid after 1970. It also implied an artificial time-zone transition at the start of 1970 for those zones that were in DST at the start of the year (including Europe/London, which was experimenting with "permanent DST" at the time, along with all southern-hemisphere zones that used DST). Changes to standard time prior to 1970 were also ignored by this.

The 2037 bound has been made redundant by the switch to 64-bit time_t on most platforms. Even so, not all platforms support the time_t functions for the full range of values that type and the associated struct tm can represent.

The initial "fix" for this, to remove code that artificially imposed these cut-offs, required care to work out sensibly (using QTimeZone where available) what offsets from UTC to use outside the range supported by each platform's time_t functions. The existing kludge to extrapolate outside the supported range failed to take account of the varying pattern of days of the week from one year to another implying that transition dates – commonly specified as "last Sunday of March" and similar – were incorrectly represented. Once that was sorted out, the previously-unexercised bugs in time-zone backend code came to light, that have had to be fixed.

I hope I can make a reasonably engaging story out of that while, in the process, making clear that Qt 6.3 is now safe from the "32-bit time_t problem" or "2038 bug".