Thomas Munro <thomas.munro@xxxxxxxxx> writes: > FreeBSD users already have the choice between zoneinfo from base or > the misc/zoneinfo port if for some reason they want to control tzdata > updates separately. PostgreSQL and FreeBSD both track tzdata closely, > and both pushed a commit for version 2019c into their stable branches > within a couple of weeks of it being released, so I don't foresee any > problem with this change, and staying in sync with libc seems to > outweigh any other concerns IMHO. Note that the normal situation, on a platform with a well-maintained tzdata package, is that tzdata acquired via Postgres is going to lag behind. That's because we don't ship tzdata updates until our next quarterly release, while the OS vendor probably has a much more streamlined process for package updates. In the case of 2019c, I pushed it into our code while it was still pretty fresh, because it was just a few days to 12rc1 and I thought the RC should contain the latest tzdata. But usually we only bother to sync from tzdata upstream when a quarterly release is impending. In theory, it's possible that a tzdata update could break Postgres. But it'd probably break a lot of other code too. In practice, the IANA people are well aware of that hazard, so there is a *long* delay between when they introduce a new tzcode feature and when they're willing to start relying on it in tzdata. We try to stay fairly current on our copy of tzcode, so that should only be a live hazard for out-of-support Postgres branches. (I was reminded of this just the other day when I had occasion to run the 9.2 regression tests, and they failed because of a no-longer-valid assumption about Venezuelan time. I should rebuild that legacy installation without --with-system-tzdata, I guess, so that it uses tzdata it's expecting.) regards, tom lane
