Make pg_interpret_timezone_abbrev() check sp->defaulttype too. This omission caused it to not recognize the furthest-back zone abbreviation when working with timezone data compiled with relatively recent zic (2018f or newer). Older versions of zic produced a dummy DST transition at the Big Bang, so that the oldest abbreviation could always be found in the sp->types[] array; but newer versions don't do that, so that we must examine defaulttype as well as the types[] array to be sure of seeing all the abbreviations.
While this has been broken for six or so years, we'd managed not to notice for two reasons: (1) many platforms are still using ancient zic for compatibility reasons, so that the issue did not manifest in builds using --with-system-tzdata; (2) the oldest zone abbreviation is almost always "LMT", which we weren't supporting anyway (but an upcoming patch will accept that). While at it, update pg_next_dst_boundary() to use sp->defaulttype as the time type for non-DST zones and times before the oldest DST transition. The existing code there predates upstream's invention of the sp->defaulttype field, and its heuristic for finding the oldest time type has now been subsumed into the code that sets sp->defaulttype. Possibly this should be back-patched, but I'm not currently aware of any visible consequences of this bug in released branches. Per report from Aleksander Alekseev and additional investigation. Discussion: https://postgr.es/m/CAJ7c6TOATjJqvhnYsui0=co5xfmf4dvtgh+skzb--jnhqsq...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bc10219b9c8931ff4f872b3e799da2208101c574 Modified Files -------------- src/timezone/localtime.c | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-)
