Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> Tom's "fix" of backpatching 23bd3cec6 (which happened on Friday 14th)
> addressed only a subset of cases, as far as I know working only on Linux
> (the historical convention has always been for /etc/localtime to be a
> copy of a zonefile, not a symlink to one). I only decided to write (and
> if need be commit) my own followup fix after confirming that the bug was
> unfixed in a default FreeBSD install when set to UTC, and there was a
> good chance that a number of other less-popular platforms were affected
> too.
I think your info is out of date on that.
NetBSD uses a symlink, and has done for at least 5 years: see
set_timezone in
http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.sbin/sysinst/util.c?only_with_tag=MAIN
macOS seems to have done it like that for at least 10 years, too.
I didn't bother digging into their source repo, as it's likely that
System Preferences isn't open-source; but *all* of my macOS machines
have symlinks there, and some of those link files are > 10 years old.
I could not easily find OpenBSD's logic to set the zone during install,
if they have any; but at least their admin-facing documentation says to
create the file as a symlink:
https://www.openbsd.org/faq/faq8.html#TimeZone
and there are plenty of similar recommendations found by Mr. Google.
In short, I think FreeBSD are holdouts not the norm. I note that
even their code will preserve /etc/localtime's symlink status if
it was a symlink to start with: see install_zoneinfo_file in
https://github.com/freebsd/freebsd/blob/master/usr.sbin/tzsetup/tzsetup.c
regards, tom lane