love2d and Lua os.date: Interoperability Question on Time Zone Handling

In LÖVE 11.4, os.date and os.time defer to the host process's local timezone as set by the underlying C runtime. No API exists to override or query a specific offset at runtime.

Confirmed constraints

• Setting TZ after the process has started typically has no effect on os.date output on Windows and macOS, because the C library caches the timezone at startup.
• On Linux with glibc, setting TZ before the first call to os.date may take effect, but changing it later is unreliable.
• Daylight‑saving transitions create region‑specific ambiguous or non‑existent local times, leading to inconsistent hour‑shift behavior across operating systems.

Practical steps for this case

1. Determine the target platform. On Linux, set TZ in the environment before launching the LÖVE process; avoid changing it at runtime.
2. On Windows and macOS, plan for a process restart if a timezone change is required, as the C runtime does not propagate TZ changes after startup.
3. For cross‑region display, compute a fixed offset from UTC at initialization and apply it manually to os.date results, rather than relying on the host timezone.
4. When straddling a DST transition, log os.time values across the boundary on each platform to verify hour-skips or repeats, then adjust your game's clock logic accordingly.

To tailor these steps to your deployment environment, please specify the target operating system and whether the timezone adjustment needs to occur before or after the game process starts.