panics in chrono local-time resolution and aborts the process when chrono cannot resolve the host timezone

[bbabnikk]

Summary

scc panics during initialization when chrono cannot resolve a valid local time. On Wine/Proton this happens reliably because Wine frequently fails to match the host timezone to an entry in the prefix's timezone registry, leaving chrono to resolve a local time that does not exist.

Because the panic occurs in a function that cannot unwind, Rust aborts rather than propagating an error. Consequences:

• Standalone (scc.exe): aborts with c0000409, printing the panic to stderr.
• In-process (scc_lib.dll via RED4ext's InvokeScc): the abort kills the game process, surfacing as an unhandled 0xE06D7363 roughly 2 seconds after launch with no diagnostic output whatsoever — no redscript log is ever created, and RED4ext's log ends normally.

This does not require any .reds files. r6/scripts/ was empty for every reproduction. The failure is at logger initialization, before any compilation work begins.

Root cause

Panic output from scc.exe run standalone under Wine:

thread '<unnamed>' panicked at C:\Users\runneradmin\.cargo\registry\src\index.crates.io-.../chrono-0.4.41\src\offset\local\mod.rs:189:46:
No such local time
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at library\core\src\panicking.rs:225:5:

panic in a function that cannot unwind

stack backtrace:

...

thread caused non-unwinding panic. aborting.

err:seh:NtRaiseException Unhandled exception code c0000409 flags 1 addr 0x6ffffdfabdd6

Immediately preceding it, Wine reports it cannot resolve the timezone:

fixme:ntdll:find_reg_tz_info Can't find matching timezone information in the registry
for bias 420, std (d/m/y): 1/11/2026, dlt (d/m/y): 8/03/2026

Note the reported bias corresponds to UTC-7 while the DST transition dates are the standard North American rules. Wine appears unable to reconcile these against its registry entries, and chrono's local-offset resolution then lands in a nonexistent local time.

Environment

  |   -- | -- OS | CachyOS (Arch-based), x86-64 Game | Cyberpunk 2077 + Phantom Liberty, Steam, patch 2.31 Game build | 3.0.5294808, file version 3.0.80.51928 redscript (failing) | 5.31 redscript (not affected) | 5.16 — last release before scc_lib.dll was introduced RED4ext | 1.30.0 Proton tested | proton-cachyos-11, Proton 9, Proton Experimental, GE-Proton 11 — all reproduce Prefix components | d3dcompiler_47, vcrun2022 DLL overrides | winmm, version = native,builtin

Steps to reproduce

1. Cyberpunk 2077 patch 2.31 on Linux via Proton, in a prefix where Wine logs find_reg_tz_info Can't find matching timezone information in the registry.
2. Install RED4ext 1.30.0. Confirm the game launches and RED4ext initializes cleanly.
3. Install redscript 5.31. Leave r6/scripts/ empty.
4. Launch → game terminates at ~2s, 0xE06D7363, no redscript log created.
5. Delete engine/tools/scc_lib.dll → game launches normally.
6. Run scc.exe standalone to see the panic directly:

   wine "…/engine/tools/scc.exe" -compile "…/r6/scripts"

Suggested fix

Two independent issues, either of which would prevent the fatal outcome:

1. Don't panic on local-time resolution. chrono's local-offset APIs are fallible by design; LocalResult::None is a legitimate outcome during DST gaps and on systems with unresolvable timezone data. Log timestamps could fall back to UTC, or use a monotonic/UTC clock outright. A logger failing to determine the local offset should not be fatal.
2. Don't let panics cross the C API boundary. The scc/capi entry points should catch unwinding (catch_unwind) and return an error code, so an internal panic surfaces to the caller as a compilation failure rather than aborting the host process. As-is, any panic anywhere in scc is an unrecoverable crash of the game for users of the in-process path.

The second point is what makes this severe rather than annoying. Under out-of-process invocation the same panic is merely a failed compile; in-process it destroys the game with no diagnostic trail.

Impact

For affected Linux users the game becomes unlaunchable with redscript installed, and the failure presents identically to a corrupted game install — There is no log output pointing at redscript, so the cause is effectively undiscoverable without a Wine debug log and manual analysis of SEH exception parameters.

Workaround

Force a resolvable timezone before launch:

TZ=UTC %command%

Ruled out

• Other mods — reproduced with only RED4ext and redscript installed.
• Compilation logic — r6/scripts/ empty; the panic precedes any compilation.
• Proton version — four builds tested, all reproduce.
• MSVC runtime — vcrun2022 installed; all VCRUNTIME140* / MSVCP140* confirmed loading.
• Stale script cache — final.redscripts restored via Steam verify before each test.
• Leftover mod files — reproduced after deleting the entire game directory and reinstalling.

Happy to provide

Full Wine debug log, complete REDengine crash report, or additional instrumented runs — the reproduction is reliable and takes about a minute.

Please ignore all the emdashes, yes I had claude write the bug report, doesn't negate the last 6 hours it took me to figure this out enough to make it an easy fix.