fix: reject invalid server timezone (e.g. Etc/Unknown) before it reac…

[ceotjoe]

What does this PR do?

Summary

• On minimal Linux Docker containers without a TZ environment variable set, Node's Intl.DateTimeFormat().resolvedOptions().timeZone returns "Etc/Unknown". This string is accepted by Node but rejected by browsers with RangeError: invalid time zone: Etc/Unknown, crashing the entire dashboard.
• Server fix (server/routes/config-routes.js): validate the resolved timezone with Intl.DateTimeFormat in a try/catch before sending it to the client. Any invalid value (including "Etc/Unknown") is replaced with '', which tells the client to fall back to the browser's own timezone.
• Client fix (src/hooks/app/useTimeState.js): apply the same validation guard before passing the timezone to toLocaleTimeString/toLocaleDateString, so a bad value can never crash the dashboard even if it somehow slips through in the future.

Reproduction

1. Deploy via Docker/Portainer without a TZ environment variable set
2. Open the app — dashboard fails immediately with RangeError: invalid time zone: Etc/Unknown

Workaround for existing deployments

Add TZ=Europe/Berlin (or your local IANA timezone) to the Portainer stack environment variables. This fix makes that optional rather than required.

Test plan

• Deploy via Docker without TZ set — dashboard loads, local time shows browser timezone
• Deploy via Docker with TZ=America/New_York — local time reflects that timezone correctly
• Open Settings → Timezone, manually select a timezone — still works as before
• Verify no regression on bare-metal / non-Docker deployments

Type of change

• Bug fix
• New feature
• Performance improvement
• Refactor / code cleanup
• Documentation
• Translation
• Map layer plugin

Checklist

• App loads without console errors
• Tested in Dark, Light, and Retro themes
• Responsive at different screen sizes (desktop + mobile)
• If touching server.js: caches have TTLs and size caps (we serve 2,000+ concurrent users)
• If adding an API route: includes caching and error handling
• If adding a panel: wired into Modern, Classic, and Dockable layouts
• No hardcoded colors — uses CSS variables (var(--accent-cyan), etc.)
• No .bak, .old, console.log debug lines, or test scripts included

[accius]

Review — reject invalid server timezone

Clean, targeted bug fix with defense-in-depth (validate on the server, validate again on the client). Correct diagnosis of the Etc/Unknown case and well-scoped.

Suggestions (non-blocking):

1. Memoize the client-side validation. useTimeState runs its try { Intl.DateTimeFormat(...) } catch on every render. Not expensive, but trivially improved by:

   const safeTimezone = useMemo(() => {
     if (!timezone) return '';
     try { new Intl.DateTimeFormat(undefined, { timeZone: timezone }); return timezone; }
     catch { return ''; }
   }, [timezone]);

   and then use safeTimezone below.

2. Log at least once server-side when the fallback kicks in, so self-hosters see something useful in the logs rather than silently getting browser-local time. A single console.warn('[config] Invalid resolved timezone "%s" — falling back to empty (client will use browser TZ). Set TZ env var to silence.', tz) is enough.

3. Intl.DateTimeFormat('en-US', …) — the locale is irrelevant for the validation; new Intl.DateTimeFormat(undefined, { timeZone: tz }) reads a little more clearly.

4. Consider documenting in the Docker/self-hosting README that TZ is optional after this fix but recommended for accurate server-side time stamps (logs, cache TTLs, etc.).

Test plan items are not ticked — please run at least the "Docker without TZ" repro and confirm before merge.

Approved as-is if the useMemo nit is out of scope; happy to merge.

[ceotjoe]

Thanks for the thorough review — all four points addressed in the follow-up commit (d045c41).

• Memoized validation — wrapped in useMemo([timezone]) so the Intl.DateTimeFormat probe only fires when the timezone value actually changes.
• console.warn on fallback — server now logs the bad value with a hint to set TZ, so self-hosters have something actionable in their container logs.
• Locale removed — both the server and client now use new Intl.DateTimeFormat(undefined, …).
• Docs — added a note to docs/DOCKER.md that TZ is optional after this fix but recommended for server-side timestamp accuracy (logs, cache TTLs).

Docker without TZ runs as expected in my case.