MSBuild incremental build error: output considered up to date despite source changes

Goal

The goal is to understand how MSBuild’s incremental build logic reacts to changes in the operating system’s time zone, and whether a normalization to UTC is necessary to prevent spurious rebuilds.

Constraints & Uncertainty

MSBuild compares source file last‑write timestamps against output timestamps to decide if a project is up to date. On Windows, these timestamps are typically interpreted in the local time zone. Altering the system time zone or moving a workspace between machines in different zones can reorder these timestamps, potentially causing MSBuild to rebuild unchanged projects or skip necessary rebuilds. The current Visual Studio releases expose no user‑visible setting to enforce UTC normalization for these comparisons.

Unresolved Questions

1. Does MSBuild compare file timestamps using the local time zone or UTC, and has this behavior changed across recent Visual Studio releases?
2. Is there a documented mechanism (e.g., a build property or command‑line switch) to force MSBuild to normalize timestamps to UTC for incremental build decisions?
3. What impact does a time‑zone change have on incremental build decisions for SDK‑style versus legacy C# projects, and how can this be reliably reproduced?