FileUpdate date insertion produces machine-dependent output (and 6 tests fail) when regional settings override the date separator

Summary

FileUpdate formats dates with CultureInfo.CurrentCulture (FileUpdate.cs:120), which picks up Windows per-user regional customizations. Because / in a .NET custom date format string is a separator placeholder rather than a literal, any DateFormat containing / renders differently depending on the machine's regional settings.

This affects the task's own default format, dd/MMM/yyyy.

Reproduction

Set the Windows short date format to yyyy-MM-dd (Settings -> Time & language -> Language & region -> Regional format -> Change formats), leaving the culture at en-US. Then:

CurrentCulture   : en-US
DateSeparator    : '-'
ShortDatePattern : yyyy-MM-dd

(2026-04-16).ToString("dd/MMM/yyyy", CurrentCulture)   -> 16-Apr-2026
(2026-04-16).ToString("dd/MMM/yyyy", InvariantCulture) -> 16/Apr/2026

dotnet test SIL.BuildTasks.Tests then fails 6 tests in FileUpdateTests — every case whose expected value contains a literal /:

• GetModifiedContents_DateLiteral_InsertsDateWithSpecifiedDateFormat (3 cases)
• GetModifiedContents_SpecialDatePlaceholderButFileDoesNotSpecifyFormat_InsertsDateWithSpecifiedDateFormat (1 case)
• GetModifiedContents_SpecialDatePlaceholderWithFileSpecifyingMultipleFormats_InsertsDateWithFormatsFromFile (2 cases)

Cases using - as the separator (dd-MM-yy, MM-yyyy) pass, since - is a literal in custom format strings. CI passes because the runners use default regional settings.

Impact

Build output is not reproducible across machines. A developer or CI agent with customized regional settings writes a different date into release notes, installers, or any other file FileUpdate touches, with no warning. The default DateFormat is affected, so a project need not opt into anything unusual to hit this.

The same applies to : in a format string, which is the time separator placeholder, and which the placeholder regex at FileUpdate.cs:126 explicitly permits.

Suggested fix

Construct the culture with user overrides disabled, which keeps localized month names working (the point of FileLocalePattern) while making separators depend only on the culture identity:

var culture = GetCultureFromFileName()
    ?? new CultureInfo(CultureInfo.CurrentCulture.Name, useUserOverride: false);

Verified on the affected machine:

FileUpdate.cs:165 has the same exposure: new CultureInfo(locale) honors user overrides when locale matches the machine's default culture, so it should pass useUserOverride: false too.

Also worth tidying

GetModifiedContents_SpecialDatePlaceholderWithFileSpecifyingMultipleFormats_InsertsDateWithFormatsFromFile is internally inconsistent — it computes two expected segments via ToString(format) (which tracks the culture) but hardcodes the middle one as 16/Apr/2026 (FileUpdateTests.cs:157). That is why only part of the assertion fails. Once the fix lands, a test pinning the culture explicitly would catch regressions regardless of the runner's regional settings.

Start in SIL.BuildTasks/FileUpdate.cs at the date-formatting code around lines 120, 126, and 165, then review the six named cases in SIL.BuildTasks.Tests/FileUpdateTests.cs. Run dotnet test SIL.BuildTasks.Tests with customized regional settings and pin the culture behavior so separators are stable while localized month names remain supported. Done means the affected tests pass consistently across regional settings.