Long-running daemon does not reflect updated /etc/localtime after timezone change

Goal: Determine how a long‑running Linux service can detect and apply a new system timezone (e.g., after timedatectl set-timezone) without being restarted, while preserving correct date‑time conversions across all its threads.

Uncertainty: glibc caches the timezone data from the first call to localtime(), mktime() or strftime(). Editing /etc/localtime or changing the TZ environment variable does not update that cache until tzset() is invoked or the process restarts. In a multi‑threaded program, calling tzset() concurrently with timezone‑conversion functions may lead to torn or inconsistent state, and there is no documented portable signal or hook that automatically triggers a cache refresh.

Questions:

• Is it safe to call tzset() from a signal handler (e.g., SIGUSR1) in a multi‑threaded daemon?
• Does glibc provide any mechanism to invalidate or refresh the cached timezone data without a full process restart?
• What are the recommended patterns for daemons to reload timezone information reliably across threads?