Introduction

Checking whether a DateTime falls inside a range is conceptually simple, but the details matter. The main questions are whether the range is inclusive or exclusive, whether the values are in the same time zone, and whether you actually mean date only instead of full timestamp comparison.

In C#, the comparison itself is just operator logic. Most bugs come from unclear range rules or mixing DateTime values with different Kind semantics.

The Basic Comparison

If you want an inclusive range, the simplest check is:

1using System;
2
3static bool IsBetweenInclusive(DateTime value, DateTime start, DateTime end)
4{
5    return value >= start && value <= end;
6}
7
8var start = new DateTime(2026, 3, 1, 0, 0, 0, DateTimeKind.Utc);
9var end = new DateTime(2026, 3, 31, 23, 59, 59, DateTimeKind.Utc);
10var value = new DateTime(2026, 3, 11, 12, 0, 0, DateTimeKind.Utc);
11
12Console.WriteLine(IsBetweenInclusive(value, start, end));

That is enough when all three values are comparable in the same time basis.

Inclusive Versus Exclusive Ranges

You must decide what between means.

Common choices:

• Inclusive: value >= start && value <= end
• Exclusive: value > start && value < end
• Half-open: value >= start && value < end

Half-open ranges are common in scheduling and reporting because they avoid overlap between adjacent intervals. For example, one range can end exactly when the next range begins without both matching the same instant.

1static bool IsBetweenHalfOpen(DateTime value, DateTime start, DateTime end)
2{
3    return value >= start && value < end;
4}

If your range logic feels inconsistent at boundaries, this is usually the first thing to clarify.

Guard Against Reversed Ranges

A small defensive improvement is to validate the input range:

1static bool IsBetweenInclusive(DateTime value, DateTime start, DateTime end)
2{
3    if (start > end)
4        throw new ArgumentException("start must be earlier than or equal to end");
5
6    return value >= start && value <= end;
7}

Without that guard, reversed inputs can silently produce confusing results.

DateTime Versus DateTimeOffset

If your values come from different time zones or cross system boundaries, DateTimeOffset is often safer than DateTime. A plain DateTime can represent local time, UTC, or unspecified time, and comparing mixed kinds can be misleading.

Example with DateTimeOffset:

1using System;
2
3static bool IsBetweenInclusive(DateTimeOffset value, DateTimeOffset start, DateTimeOffset end)
4{
5    return value >= start && value <= end;
6}
7
8var start = new DateTimeOffset(2026, 3, 1, 0, 0, 0, TimeSpan.Zero);
9var end = new DateTimeOffset(2026, 3, 31, 23, 59, 59, TimeSpan.Zero);
10var value = new DateTimeOffset(2026, 3, 11, 8, 0, 0, TimeSpan.FromHours(-4));
11
12Console.WriteLine(IsBetweenInclusive(value, start, end));

DateTimeOffset preserves the offset and makes time comparisons more explicit.

If You Mean Date Only

Sometimes the real requirement is same calendar date range rather than full timestamp range. In that case, compare .Date values or normalize the timestamps before checking:

1using System;
2
3DateTime value = new DateTime(2026, 3, 11, 18, 45, 0);
4DateTime start = new DateTime(2026, 3, 1);
5DateTime end = new DateTime(2026, 3, 31);
6
7bool inRange = value.Date >= start.Date && value.Date <= end.Date;
8Console.WriteLine(inRange);

This avoids accidental failures caused by time-of-day components you did not intend to compare.

Encapsulate the Range

If range checks happen in many places, wrap the logic in a small type so the rules stay consistent:

1using System;
2
3public readonly record struct DateRange(DateTime Start, DateTime End)
4{
5    public bool Contains(DateTime value) => value >= Start && value < End;
6}
7
8var range = new DateRange(
9    new DateTime(2026, 3, 1, 0, 0, 0, DateTimeKind.Utc),
10    new DateTime(2026, 4, 1, 0, 0, 0, DateTimeKind.Utc)
11);
12
13Console.WriteLine(range.Contains(DateTime.UtcNow));

This makes it much harder for boundary logic to drift across the codebase.

Common Pitfalls

The most common mistake is mixing inclusive and exclusive logic without realizing it. Boundary bugs often come from one method using <= end and another using < end.

Another common issue is comparing local time with UTC or unspecified DateTime values. The comparison operators work, but the result may not match real-world time intent.

People also forget that DateTime includes a time component. If you compare a range ending at midnight, a later time on the same calendar day may fall outside the range unexpectedly.

Finally, do not ignore reversed ranges. Failing fast is better than quietly returning false for every comparison.

Summary

• A range check in C# is usually a simple comparison once the boundary rules are clear.
• Decide explicitly whether the range is inclusive, exclusive, or half-open.
• Use DateTimeOffset when time-zone correctness matters.
• Compare .Date values if the requirement is calendar-date logic rather than full timestamps.
• Encapsulate the range rule so all callers use the same boundary behavior.