Per-game virtual clock

[Dil3mm4]

Per-game virtual clock for native builds

This is: An idea

What happens, or what you would like

I would like a per-game date/time override for native builds.
Some games react to wall-clock dates or time progression, but changing the macOS system date affects every other application, and a fully frozen guest clock does not model a normally advancing day.

In the game's Launch options, I would like to select a starting date/time and choose one of three modes:

1. Off: the guest sees normal time.
2. Restart on launch: the guest begins at the selected time on every launch and advances normally during the session.
3. Continue between sessions: the guest begins at the selected time and accounts for real elapsed time, even while the game is closed.

The change should apply only to that game's guest wall-clock APIs.
It must not set the host clock or alter monotonic/steady clocks used for timing and scheduling.
The launcher should save the choice per game alongside its existing settings and clearly explain when a rebuilt game app is required to enable it.

I have a scoped macOS implementation and tests in my fork at feature/virtual-clock.
I am opening this idea for design agreement and milestone assignment before a feature PR, per CONTRIBUTING.md.
Milestone v1.6.0 covers launch options and may be a fit, but I am not assuming approval or assignment.
Prior clock-service work (#26) handles adjustable system-clock snapshots; it does not add a per-game wall-clock override.

Design trade-offs considered:

• Changing the global system date: rejected because it affects other apps, certificates, sync and OS behavior.
• A single frozen timestamp: inadequate when the game should observe passing time.
• Per-title wall-clock virtualization: confines behavior to the guest and lets steady clocks remain untouched.

Initially macOS-focused. iOS parity, the accepted naming/UI and engine-side placement should be discussed with maintainers.
The implementation includes an nxnative engine patch; I will coordinate whether that should be forwarded upstream.

What you expected

A player can choose a simulated date/time for one native game, decide whether the game should resume elapsed time after being closed, and keep the host computer's clock untouched.
The feature remains opt-in and the default behavior stays unchanged.

NX2Apple version

Upstream main at 932004ff6aba376f1ce5f25c738454dfdd3f9752; proposed fork branch feature/virtual-clock at tip 06c30b27 (clock host-test stub: 507423a2) (8 November 2026).
The default host C test now links and passes without overrides.