Ugh. It doesn't have the old backward compatibility names like US/Pacific installed by default, which is a problem if that's what initdb picked for your cluster (or you've stored references to any of those names in other ways).
One quick fix is to revert the change. Tom thinks this is not reason to revert. Would it be enough to edit the postgresql.conf to use the correct "modern" name for US/Pacific (PST?)? In rhar case, an update note might be sufficient?
I think the "official" name of that zone is America/Los_Angeles. But initdb might seize on the US/Pacific alias, if available, because it's shorter. We've seen related problems with other time zone names, though usually it was just cosmetic and not a reason for the postmaster to fail to start.
Yes, changing the zone name in postgresql.conf should be a sufficient fix. In theory, a FreeBSD user ought to know the "official" alias for their zone, since the rest of the system would expect that. So this is slightly tedious if initdb chose a non-official alias, but I don't think it's reason to panic.
Perhaps the best thing would be to revert this for the older PostgreSQL releases so that people doing minor version upgrades are inconvenienced by a system that can't start up after "pkg upgrade", but do it for 12 since not many people will be using that yet?
That could be a way, yes. Any thoughts on this from others following this thread?
