UTC Default vs Custom TZ Environment Variable for Regional Time Handling on Glitch

Recommendation

Keep Glitch’s UTC system clock and handle all time‑zone conversion in application code.

Confirmed facts

• Glitch containers run on UTC by default; Node.js inherits this clock.
• Setting TZ in .env changes process.env.TZ and shifts the output of Date.prototype.toString() and toLocaleString(), but toISOString() always stays UTC.
• A TZ value is only applied to processes that load the .env file; background workers or externally triggered jobs may not see it unless the variable is part of the project environment.
• After a restart or container migration the TZ variable is not guaranteed to persist.

Likely explanation

If you rely on TZ for server‑side timestamps, a lost variable will cause logs, scheduled jobs, and any code that uses the default Date format to drift back to UTC, creating inconsistency and potential duplicate or missed job runs around DST transitions.

Steps to adopt the UTC‑default approach

1. Do not define TZ in your .env file.
2. Store all timestamps (e.g., in a database) as UTC strings (using toISOString()) or Unix epoch numbers.
3. When you need to display a time in a specific region, format it at render time using Intl.DateTimeFormat (or a library such as date‑fns‑tz) with the desired IANA zone identifier.
4. For logs, let the Node.js process emit timestamps in UTC; if you must see local time in log files, apply the same formatting in your logging library or post‑process the logs.
5. Verify the setting after any restart:

• Run a one‑liner in the Glitch console that prints process.env.TZ (or shows it is undefined).
• Check that new Date().toISOString() changes uniformly with real‑world time while new Date().toString() reflects UTC when TZ is not set.
• Repeat the check after a project restart to confirm the behavior is stable.

One missing diagnostic detail

Do you require OS‑level logs, external monitoring tools, or scheduled‑job systems to display timestamps in your local time rather than UTC? If the answer is yes, you may need to set TZ explicitly and verify its persistence after each restart; otherwise, the UTC‑default approach remains the safer choice.