Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta Adatta ai principianti
  • Qualcosa non va?
#91 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
88/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
build-system

Direzione di ricerca

Inizia in SIL.BuildTasks/FileUpdate.cs, nel codice di formattazione delle date intorno alle righe 120, 126 e 165, poi esamina i sei casi indicati in SIL.BuildTasks.Tests/FileUpdateTests.cs. Esegui dotnet test SIL.BuildTasks.Tests con impostazioni locali personalizzate e fissa il comportamento della cultura affinché i separatori siano stabili e i nomi dei mesi localizzati restino supportati. Il lavoro è completato quando i test interessati passano in modo coerente con impostazioni locali diverse.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
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:

Culture dd/MMM/yyyy d MMMM yyyy
CurrentCulture (overrides on) 16-Apr-2026 —
same name, useUserOverride: false 16/Apr/2026 —
new CultureInfo("fr", false) — 16 avril 2026

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.

Lingua principale
C#
Stelle
5
Fork
3
Merge medio
8h 23m
PR unite (30g)
4

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sillsdev/SIL.BuildTasks

Tutte le issue di sillsdev/SIL.BuildTasks

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.