That can easily lead to breaking tests due to time-zones, daylight saving time or the variable length of months.

We experienced several of those over the years, and generally it was the test that was wrong, not the code it was testing.

For example, this simplified test hits several of those pitfalls:

    var expected = start.AddMonths(1);
    var actual = start.ToLocal().AddMonths(1).ToUtc();
    Assert(expected == actual);

That introduces dependency of a clock which might be undesirable, just had a similar problem where i also went for hardcoding for that reason.

Because it should be `today + 1 year + randomInt(1,42) days`.

Always include some randomness in test values.