Update our timezone code to IANA tzcode2026b
Here's a patch to do $SUBJECT. I looked into this due to Andres'
report of a Valgrind uninitialized-memory complaint [1]/messages/by-id/4uukubkg3t5eavtxxzfa7smqbnqqvl3ysl7aptmj77zbtdxjh3@krjnfntcirw6. I can
confirm that Valgrind no longer complains about this code.
However, it seems like the uninitialized-memory issue didn't
have any practical effect. The files generated by zic are
mostly the same as before, and for the couple dozen that are
not, testing with "zdump -v" shows that they represent the same
set of timestamp transitions as before. I suppose that those
changes are from internal algorithmic changes in zic. One file
that changed was Asia/Tbilisi, which is called out in the upstream
release notes for 2026a as no longer containing a useless no-op
transition. I didn't bother trying to trace down the other data
changes.
There are a lot of changes in this patch, since we hadn't done
a similar update since 2020. One that is rather annoying for
our purposes is that they changed the signatures of both
tzload() and tzparse(). Which they're entitled to do, both
of those being internal to localtime.c --- except we'd unwisely
exposed them as additional API. I think the best thing to do
is make them both local functions again, so that they can
track upstream, and instead export our own wrapper function.
A question that immediately raises is whether it's enough of
an API break to prevent back-patching this. Historically we've
usually back-patched tzcode updates to ensure that we'll still
be able to read future tzdata updates, and I was intending to
do so again with this. But perhaps this API break is a reason
not to. I don't see any really strong reason why extension
modules would be calling tzload() or tzparse(), but maybe
somebody is. So at the moment I'm leaning to "no backpatch".
I'll park this in the upcoming CF for now.
regards, tom lane
[1]: /messages/by-id/4uukubkg3t5eavtxxzfa7smqbnqqvl3ysl7aptmj77zbtdxjh3@krjnfntcirw6
Attachments:
v1-0001-Sync-our-copy-of-the-timezone-library-with-IANA-r.patchtext/x-diff; charset=us-ascii; name*0=v1-0001-Sync-our-copy-of-the-timezone-library-with-IANA-r.p; name*1=atchDownload+3066-1875
I wrote:
Here's a patch to do $SUBJECT.
cfbot didn't like v1 too much, here's a v2.
regards, tom lane
Attachments:
v2-0001-Sync-our-copy-of-the-timezone-library-with-IANA-r.patchtext/x-diff; charset=us-ascii; name*0=v2-0001-Sync-our-copy-of-the-timezone-library-with-IANA-r.p; name*1=atchDownload+3043-1879
On 01.06.26 02:55, Tom Lane wrote:
I wrote:
Here's a patch to do $SUBJECT.
cfbot didn't like v1 too much, here's a v2.
I know you have already reported this upstream, but here are some
patches to silence the resulting warnings on MSVC.
Patch 0001 just silences the warnings using pragmas.
Patch 0002 is to silence the "unary minus operator applied to unsigned
type" warning globally for PostgreSQL. AFAICT, there is no equivalent
warning available on gcc or clang, so this would remain a trap on MSVC.
Patch 0003 is to silence the cross-enum comparison warnings using casts
(as you had suggested to upstream). I confirmed that this works in a
small test case on Compiler Explorer (godbolt.org), but if I push this
branch to GitHub Actions CI, the warning remains, so I don't know about
this one.
Attachments:
0001-Fix-MSVC-warnings-from-new-timezone-code.patchtext/plain; charset=UTF-8; name=0001-Fix-MSVC-warnings-from-new-timezone-code.patchDownload+14-1
0002-Disable-MSVC-warning-C4146-globally.patchtext/plain; charset=UTF-8; name=0002-Disable-MSVC-warning-C4146-globally.patchDownload+1-16
0003-Use-a-different-trick-to-silence-warnings-about-cros.patchtext/plain; charset=UTF-8; name=0003-Use-a-different-trick-to-silence-warnings-about-cros.patchDownload+3-11
Peter Eisentraut <peter@eisentraut.org> writes:
I know you have already reported this upstream, but here are some
patches to silence the resulting warnings on MSVC.
Since Eggert doesn't seem to want to do anything about these,
I was planning on just ignoring them (and have already adjusted
my warning-scraping script to do so). I don't think inserting
diffs from tzdb upstream is a good tradeoff, so I definitely
don't like your 0001. I'd be okay with 0002's solution (suppress
the unary-minus complaint globally). I might hold my nose for
0003, but you say it doesn't seem to work, so ...
(BTW, the links cited in the tzdb thread suggest that whether
MSVC will warn about 0003's fix depend on how recent it is.
So maybe if we got a newer MSVC into our CI infrastructure,
it'd work?)
regards, tom lane