Killian Brendel las im .NET-Reference-Source und stieß auf den Kommentarblock des TimeSpan-Structs. Zunächst klingt alles vernünftig: Ein TimeSpan ist eine Zeitdauer, kann negativ oder positiv sein und wird intern als Anzahl von Millisekunden gespeichert. Der Kommentar erklärt dann, warum es keine Years()- oder Months()-Methoden gibt: Monate variieren zwischen 28 und 31 Tagen und lassen sich daher nicht sauber auf Millisekunden abbilden.

Dann driftet der Text ab. Ein Jahr könne 365 oder 364 Tage enthalten, heißt es, und ein Jahrzehnt je nach Kalenderzuordnung zwischen 1 und 3 Schaltjahre haben. Ein Jahr mit 364 Tagen würde einen negativen Schalttag implizieren — ein Konzept, deutlich beunruhigender als die ohnehin gefürchtete negative Schaltsekunde.

Praktisch ist das nichts weiter als ein Tippfehler für 366, ohne jede Auswirkung auf das Verhalten der Klasse. Vermutlich deshalb liegt er seit dem Initial Commit vor zwölf Jahren unangetastet im Code. Die TimeSpan-Klasse selbst wurde in dieser Zeit kaum verändert, da sie im Kern nur ein Wrapper um eine Millisekundenzahl ist; komplexere Datumsarithmetik wie AddMonths und AddYears steckt in den darauf aufbauenden Date-Time-Typen.

Die Datei lohnt ohnehin einen weiteren Blick: Sie enthält veraltete Standardkonstruktoren und Compile-Time-Hooks für ältere .NET-Varianten, darunter Silverlight — zuletzt 2019 aktualisiert, seit 2015 in keinem großen Browser mehr unterstützt und offiziell seit 2021 aus dem Support gefallen. Vielleicht kein echtes WTF, aber eine hübsche Erinnerung daran, dass auch Microsofts Referenzquelltext seine Spinnweben hat.