Test a value of TZ that temporarily escapes from TZDIR (which is not
permitted when setugid) then reenters it.

MFC after:	3 days

* If TZ starts with TZDIR, strip any additional slashes so relname
  does not end up looking like an absolute path.  For instance,
  TZ=/usr/share/zoneinfo//UTC should result in UTC, not /UTC.

* In the setugid case, we were incorrectly passing name rather than
  relname to fstatat().

* Modify the tz_env and tz_env_setugid test cases to exercise both
  of these scenarios.

* Also add test cases for invalid values of TZ, which I wrote
  earlier but forgot to include in a5f14e4f9069.

Reported by:	Paul Eggert <eggert@cs.ucla.edu>
MFC after:	3 days
Fixes:		967a49a21a27 ("Update tzcode to 2025b")
Fixes:		a5f14e4f9069 ("tzcode: Use -00 only for invalid time zones")
Reviewed by:	philip
Differential Revision:	https://reviews.freebsd.org/D52753

This catches a bug in tzcode which incorrectly considers TZDEFAULT as
unsafe as if it came from the environment.

Also deduplicate some repeated code, and fix a missing mode in an
open(2) call with O_CREAT set.

Event:		Oslo Hackathon 202508
Reviewed by:	philip
Differential Revision:	https://reviews.freebsd.org/D52241

Add a test case for a typical thin jail scenario where TZDIR does not
exist and we get our information from /etc/localtime.  This is
technically already covered by the detect_tz_changes test case, but
this new test case is independent of the DETECT_TZ_CHANGES option.

Fixes:		a6b19979bf13 ("tzcode: Fix TZ for non-setugid programs")
Differential Revision:	https://reviews.freebsd.org/D52124

The previous commit had the desired effect for setugid programs, but
broke TZ for everyone else.  I didn't notice because my test cases
swap out /etc/localtime instead of setting TZ, so add a test case
that sets TZ.

Fixes:		b6ea2513f776 ("tzcode: Limit TZ for setugid programs")
Reviewed by:	cy
Differential Revision:	https://reviews.freebsd.org/D52108

While here, clean the detection code up a bit.

Sponsored by:	Klara, Inc.
Sponsored by:	NetApp, Inc.
Reviewed by:	markj
Differential Revision:	https://reviews.freebsd.org/D51343

The day-of-week calculation used the raw year value without adjusting
for TM_YEAR_BASE, so it was off by one for 300 years out of every 400;
it just happened to be correct for 1901 through 2000.  It also used a
loop where a simple addition would have sufficed.

While here, simplify our version of Gauss's algorithm, and document
that we assume the Gregorian calendar.

MFC after:	1 week
PR:		282916
Reviewed by:	imp, allanjude, philip
Differential Revision:	https://reviews.freebsd.org/D47977