[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode"
- Reply: bugzilla-noreply_a_freebsd.org: "[Bug 290520] Sync localtime, zic, zdump from circa 2025 tzcode"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sun, 26 Oct 2025 00:02:05 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=290520
Bug ID: 290520
Summary: Sync localtime, zic, zdump from circa 2025 tzcode
Product: Base System
Version: CURRENT
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: bin
Assignee: bugs@FreeBSD.org
Reporter: eggert@cs.ucla.edu
Created attachment 264886
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=264886&action=edit
[PATCH 1/2] Prepare for syncing with upstream tzcode
I recently changed tzcode upstream to simplify syncing it to FreeBSD. Attached
please find two patches to freebsd-src's main branch to do such a sync. These
patches sync from TZDB's current main branch; if you'd prefer to wait for a
TZDB release I can make such a release whenever it's convenient to help move
this process forward.
Aside from simplifying future maintenance (the main goal), the patches sync
from TZDB's main branch, and therfore make the following behavior and
implementation changes compared to what's in freebsd-src's main branch:
* When zic -m or -u is used, create temp files with more-restrictive
permissions, to fix some unlikely security races.
* Use fchown and fchmod instead of chown and chmod, to fix some unlikely
security races.
* Do not mishandle diabolic environment settings like
TZ="/usr/share/zoneinfo/NZST-12NZDT,M9.5.0,M4.1.0/3". These settings should
fail, and not be treated as if the leading "/usr/share/zoneinfo/" is missing.
* Extend zic's -u OWNER option to also support -u OWNER:GROUP, like chown.
* Move timestamp generation out of critical sections, to allow more
parallelism.
* Use CLOCK_MONOTONIC_COARSE instead of the slower CLOCK_MONOTONIC when
DETECT_TZ_CHANGES is defined.
* In the unlikely event that clock_gettime fails, assume the cached data are
stale, as this is safer than assuming they're fresh.
* localtime/gmtime/offtime no longer fail merely because they cannot allocate a
thread-specific struct tm.
* Treat ' ' like '_' in time zone abbreviations, to avoid breaking some
timestamp parsers.
* zic now is now consistent with zdump, in that it uses argv[0] for diagnostics
if argv[0] is non-null.
* zic now checks for duplicate -m, -g, and -u options.
* zic now uses open + fdopen rather than umask + fopen, as this avoids
confusion when the -m option specifies a symbolic mode whose behavior depends
on the umask.
* Do not call stat/fstat twice on the same read-only file.
* Do not fail merely because fstat fails (e.g., with EOVERFLOW).
* Avoid an unnecessary duplicate lock in the gmtcheck function and macro.
* Avoid an unnecessary malloc+free if tzload fails early.
* Do not bother checking st_mtime; checking st_ctime suffices.
* Use strnlen instead of strlen, to improve asymptotic performance.
* Use mempcpy instead of memcpy when this seems helpful.
* Avoid some unnecessary casts and/or use of too-wide types; instead, suppress
clang's false alarms by using its -Wno-sign-compare option.
* Do not fail on a numeric mode merely because setmode fails with ENOMEM;
instead, fall back on strtoul.
--
You are receiving this mail because:
You are the assignee for the bug.