Implementation Complete ✓

• Add HaveMillisecond and NotHaveMillisecond methods to DateTimeAssertions class
• Add HaveMillisecond and NotHaveMillisecond methods to DateTimeOffsetAssertions class
• Create test file for DateTime.HaveMillisecond (6 tests)
• Create test file for DateTimeOffset.HaveMillisecond (6 tests)
• Run targeted tests to validate implementation (All 18 tests passed)
• Run broader test suite to ensure no regressions (355 DateTime/DateTimeOffset tests passed)
• Manual verification with console app (All 4 manual tests passed)
• Request code review (Completed - no blocking issues)
• Update docs/_pages/releases.md with feature summary
• Update test method naming to follow new convention
• Run AcceptApiChanges.sh to update approved API
• Verify all approval tests pass (All 4 approval tests passed)
• Remove noisy words (should, when) from test names

Summary

Successfully implemented HaveMillisecond and NotHaveMillisecond assertion methods for both DateTime and DateTimeOffset types, following the existing patterns. All tests pass successfully with no regressions detected. Test naming has been refined to follow clean naming conventions without rigid and noisy words.

This section details on the original issue you should resolve

<issue_title>Method to assert the millisecond part of a DateTime / DateTimeOffset instance</issue_title>
<issue_description>### Background and motivation

Currently, FluentAssertions has methods to assert the year, month, day, hour, minute, second and offset of a DateTimeOffset (HaveX), but an equivalent method for the millisecond part is missing. Generally, it would be nice to assert the millisecond part in the style of FluentAssertions instead of using result.Millisecond.Should().Be(milliseconds).

I'm currently working on a library that provides convenience methods based on DateTime/DateTimeOffset and implement date and time related unit tests for it.

This is very easy to implement, because we can extend the DateTimeAssertions class and DateTimeOffsetAssertions class by a method called HaveMillisecond.

The implementation of this method could look like following:

public AndConstraint<DateTimeOffsetAssertions> HaveMillisecond(int expectedMilliseconds, string because = "", params object[] becauseArgs)
{
    Execute.Assertion
      .ForCondition(this.Subject != null)
      .BecauseOf(because, becauseArgs)
      .FailWith("Expected {context:DateTimeOffset} to have milliseconds {0}{reason}, but found <null>.", expectedMilliseconds);

    Execute.Assertion
      .ForCondition(this.Subject!.Value.Millisecond == expectedMilliseconds)
      .BecauseOf(because, becauseArgs)
      .FailWith("Expected {context:DateTimeOffset} to have milliseconds {0}{reason}, but found {1}.", expectedMilliseconds, this.Subject.Value.Millisecond);

    return new AndConstraint<DateTimeOffsetAssertions>(this);
}

Also the opponent of HaveMillisecond, which would be NotHaveMillisecond, can be implemented this way by inverting / changing the condition to this.Subject!.Value.Millisecond != expectedMilliseconds.

API Proposal

public class DateTimeOffsetAssertions<TAssertions>
{
    public AndConstraint<DateTimeOffsetAssertions> HaveMillisecond(int expectedMilliseconds, string because = "", params object[] becauseArgs);
    public AndConstraint<DateTimeOffsetAssertions> NotHaveMillisecond(int expectedMilliseconds, string because = "", params object[] becauseArgs);
}

public class DateTimeAssertions<TAssertions>
{
    public AndConstraint<DateTimeAssertions> HaveMillisecond(int expectedMilliseconds, string because = "", params object[] becauseArgs);
    public AndConstraint<DateTimeAssertions> NotHaveMillisecond(int expectedMilliseconds, string because = "", params object[] becauseArgs);
}

API Usage

var dateTimeOffset = DateTimeOffset.Parse("2024-08-23T00:00:00.123+00:00");
dateTimeOffset.Should().HaveMilliseconds(123);
dateTimeOffset.Should().NotHaveMilliseconds(124);

Alternative Designs

Alternately, you could write an extension method based on DateTimeOffsetAssertions class and add there the HaveMillisecond method. This would not directly change the API of FluentAssertions, but would not be consistent with the rest of the DateTime/DateTimeOffset method provided by FluentAssertions.

The extension method could be implemented like following:

internal static class DateTimeOffsetAssertionsExtensions
{
    internal static FluentAssertions.Primitives.DateTimeOffsetAssertions HaveMillisecond(
        this FluentAssertions.Primitives.DateTimeOffsetAssertions assertions,
        int expectedMilliseconds,
        string because = "",
        params object[] becauseArgs)
        {
            var subject = assertions.Subject;
            Execute.Assertion
                .ForCondition(subject != null)
                .BecauseOf(because, becauseArgs)
                .FailWith("Expected {context:DateTimeOffset} to have milliseconds {0}{reason}, but found <null>.", expectedMilliseconds);

            Execute.Assertion
                .ForCondition(subject!.Value.Millisecond == expectedMilliseconds)
                .BecauseOf(because, becauseArgs)
                .FailWith("Expected {context:DateTimeOffset} to have milliseconds {0}{reason}, but found {1}.", expectedMilliseconds, subject.Value.Millisecond);

            return assertions;
        }
}

Risks

None, because it adds an extra method to assert the millisecond part of a DateTime / DateTimeOffset instance.

Are you willing to help with a proof-of-concept (as PR in that or a separate repo) first and as pull-request later on?

Yes, please assign this issue to me.</issue_description>

Comments on the Issue (you are @copilot ...

• Fixes Method to assert the millisecond part of a DateTime / DateTimeOffset instance #2738

🔒 GitHub Advanced Security automatically protects Copilot coding agent pull requests. You can protect all pull requests by enabling Advanced Security for your repositories. Learn more about Advanced Security.