Support POSIX TZ strings in TZif databases

[HertzDevil]

Follow-up to #15792.

[HertzDevil]

macOS CI is breaking because it explicitly sets $TZ to America/New_York, which means Time.local(9999, 12, 31, 23, 59, 59, nanosecond: 999_999_999) would return a UTC instant in the year 10000. It was originally introduced in #2682 for a spec of what is now HTTP.format_time, but that spec currently uses a fixed time zone and does not depend on $TZ anymore.

I propose unsetting $TZ in bin/ci.

[straight-shoota]

Hm, I don't know. In general, it might not be a bad idea to set an explicit time zone other than UTC. Precisely to find problems with time zone expectations.

Why is this spec suddenly broken? Why is it impossible to have a Time instance for that instant in America/New_York?

[HertzDevil]

Never mind, this is where the exception is actually raised:

crystal/src/time/tz.cr

Lines 112 to 114 in 96bf61e

	local_new_year = Time.utc(local_year, 1, 1).to_unix + (new_year_is_dst ? dst_offset : std_offset)
	local_new_year_next = Time.utc(local_year + 1, 1, 1).to_unix + (new_year_is_dst ? dst_offset : std_offset)
	break if local_new_year <= unix_seconds < local_new_year_next