Killian Brendel was looking through the .NET source code, and found this comment on the TimeSpan struct.
// TimeSpan represents a duration of time. A TimeSpan can be negative
// or positive.
//
// TimeSpan is internally represented as a number of milliseconds. While
// this maps well into units of time such as hours and days, any
// periods longer than that aren't representable in a nice fashion.
// For instance, a month can be between 28 and 31 days, while a year
// can contain 365 or 364 days. A decade can have between 1 and 3 leapyears,
// depending on when you map the TimeSpan into the calendar. This is why
// we do not provide Years() or Months().
Okay, a TimeSpan represents a duration of time. Makes sense. It can be negative or positive. Sure. It's a number of milliseconds. Okay, yeah. Other units of time get hard to represent that way, because months could have 28-31 days. Sure, yeah. I'm with you. And a year could contain 365 or 364 days, and a decade could have between 1 and 3 leapyears.
Wait, go back one. How long can a year be? I know negative leap seconds are going to be an issue, but negative leap days are gonna be way worse.
In the scheme of things, this isn't much more than a fat-finger typo. It doesn't impact the behavior of the class, which is why it's been sitting there since the initial commit, twelve years ago. The TimeSpan class itself hasn't been touched in that time, which also isn't much of a surprise, since it's really just a wrapper around a number of milliseconds. More complex date arithmetic, like AddMonths or AddYears is handled in the various date-time related objects.
So, is this a true WTF? Well, probably not. But it's interesting. Actually, the whole class is kind of interesting, as you can spot deprecated default constructors, as well as compile-time hooks for handling support for older versions of .NET including Silverlight, a technology that hasn't received an update since 2019, hasn't been supported in major browsers since 2015, and officially left support in 2021.