Sharepoint Online List Calculate If Between Two Dates

SharePoint Date Logic Calculator

Test whether a date falls inside a start and end range, choose inclusive or exclusive boundaries, and instantly generate a SharePoint calculated column formula you can adapt for your list.

What You Get

Instant evaluation, clean output, charted timeline

This tool is designed for list builders, site owners, and Microsoft 365 admins who want fast confidence before writing a calculated column or a validation rule.

• Checks whether the selected date is inside the date window.
• Shows total range length and the tested date position relative to the interval.
• Generates a SharePoint formula based on your selected boundary logic.
• Visualizes the range with a Chart.js timeline style bar chart.

How to calculate if a SharePoint Online list date is between two dates

If you are building business logic in a SharePoint Online list, one of the most common requirements is to determine whether a date falls between two other dates. This sounds simple, but in real-world list design there are several details that matter: should the start date count as inside the range, should the end date count as inside the range, are you comparing against a fixed date column or against today’s date, and what should happen if users leave one of the date fields blank? The calculator above helps you model these decisions before you commit to a formula inside your list.

At the core, the logic uses an AND comparison. In plain English, the rule says: a date is between two dates only when it is greater than or equal to the start date and less than or equal to the end date. In SharePoint calculated columns, that pattern usually looks like an IF function wrapped around an AND test. For example, if you want to evaluate whether [TargetDate] falls inside the interval defined by [StartDate] and [EndDate], your starting point is usually:

=IF(AND([TargetDate]>=[StartDate],[TargetDate]<=[EndDate]),”Yes”,”No”)

This formula is the standard inclusive version. It treats the first and last day as valid. In scheduling, approvals, booking windows, training periods, policy-effective ranges, and contract lifecycle tracking, inclusive logic is often what users expect. If the target date equals the start date, the result should be true. If the target date equals the end date, the result should also be true. That is why the operators >= and <= are so popular in SharePoint date formulas.

Why date boundary logic matters more than people think

A surprising number of list errors happen because teams agree on the idea of “between” but not on the exact rule. Some departments interpret a date range as fully inclusive, while others think “between” means strictly inside the range, excluding both endpoints. If you use the wrong interpretation in a calculated column, records can appear active one day too early or expire one day too late. In regulated workflows, retention tracking, access reviews, or compliance attestations, that one-day difference can matter.

The safest method is to define your business rule in one sentence before writing the formula. For example:

• Inclusive rule: The date is valid from the start date through the end date.
• Exclusive rule: The date must be later than the start date and earlier than the end date.
• Left-inclusive rule: The range starts immediately on the start date, but the end date itself is not included.
• Right-inclusive rule: The end date counts, but the start date does not.

The calculator above lets you switch among all four options so you can see the logical result and the formula syntax at the same time. That makes it much easier to validate the expected outcome with business owners before deployment.

Common SharePoint formula patterns

There are two major patterns used in SharePoint Online list calculations for this use case. The first compares one date column to two other date columns. The second compares today’s date to a start and end window. Both are useful, but they solve different problems.

1. Comparing a list date to a range: Useful when your item has a specific event date, delivery date, review date, or booking date.
2. Comparing TODAY() to a range: Useful when you want to know whether an item is currently active, currently valid, or currently in a review window.

If you are checking whether an item is active right now, you usually do not need a third date column at all. Instead, you compare TODAY() to the start and end fields. A classic example is:

=IF(AND(TODAY()>=[StartDate],TODAY()<=[EndDate]),”Active”,”Inactive”)

That formula is especially useful in lists used for promotions, certifications, temporary access periods, campaign windows, project phases, and policy exceptions. As long as your date columns are true date fields, SharePoint can evaluate the condition correctly.

Expert implementation guidance for SharePoint Online lists

When creating date-based formulas in SharePoint Online, you should design for readability first and optimization second. SharePoint formulas are not difficult, but they can become hard to maintain if column names are unclear or if multiple nested conditions are combined without a naming standard. The best practice is to choose short, descriptive field names like StartDate, EndDate, ReviewDate, or EffectiveDate, then keep the formula itself as direct as possible.

Recommended setup checklist

• Make sure all relevant columns use the Date and Time field type.
• Decide whether time values matter or if date-only behavior is enough.
• Pick the correct boundary rule and document it in your list design notes.
• Test sample items where the target date is before, equal to, inside, equal to the end, and after the range.
• Use a calculated column for display logic, or a Power Automate condition if you need workflow action.

Many list builders forget to test the equality cases. Those are the records most likely to reveal whether your rule is inclusive or exclusive. If your stakeholders say, “A record should still count on the end date,” your formula must use <= for the upper bound. If they say, “It expires at the start of the end date,” then your business process probably needs a different approach, especially if time-of-day values are involved.

400 Years in a full Gregorian calendar cycle

97 Leap years in each 400-year cycle

303 Common years in each 400-year cycle

These calendar facts matter because date calculations are not just simple subtraction in all contexts. The Gregorian calendar introduces leap years, varying month lengths, and edge cases around month transitions. SharePoint handles much of this for you internally when you use true date fields, but understanding the underlying structure helps you trust the output and troubleshoot unusual results.

Comparison table: boundary rule patterns and expected results

Boundary mode	Operators used	Example with Start 2025-01-10, Target 2025-01-10, End 2025-01-20	Typical use case
Inclusive	>= start and <= end	TRUE	Policies, active periods, reservations where first and last dates count
Exclusive	> start and < end	FALSE	Strict internal intervals where only fully interior dates count
Left inclusive	>= start and < end	TRUE	Windows that begin on the first day but stop before the final day starts
Right inclusive	> start and <= end	FALSE	Less common logic used in some handoff or rollover scenarios

How blank values affect your calculated column

In real SharePoint lists, users leave fields empty. That means your perfect formula can still produce unexpected output if one or more date columns are blank. If your use case allows optional end dates, you may need a formula that treats a blank end date as open-ended. Likewise, if the start date is blank, you might want to return an empty result instead of “No.” This is where extra conditional logic becomes useful.

A practical pattern is to check for blanks first, then run the date comparison only if the required values exist. Depending on your exact SharePoint syntax constraints and locale, you may use functions like ISBLANK or compare to an empty string. Because formula behavior can vary by regional settings and field configuration, always test directly in your tenant.

For example, your business rule might say:

1. If StartDate is missing, do not evaluate.
2. If EndDate is missing, treat the item as active from StartDate onward.
3. If both dates are present, compare normally.

That kind of logic goes beyond the simplest “between two dates” test, but it is extremely common in contract management, employee onboarding, access control, and expiration monitoring lists.

Comparison table: real calendar facts that affect date formulas

Calendar fact	Statistic	Why it matters in list logic
Days in a common year	365	Annual windows and anniversary calculations are usually based on 365 days in non-leap years.
Days in a leap year	366	Items spanning February in leap years can appear off by one day if manually estimated.
Leap years per 400-year Gregorian cycle	97	Date systems rely on this rule to keep long-term calendars accurate.
Months with 31 days	7	Month-end ranges do not have equal length, so visual estimation is unreliable.
Shortest month length	28 days, or 29 in leap years	February is the most common source of date-range mistakes in manual testing.

Should you use a calculated column, validation formula, or Power Automate?

The right tool depends on what you need the result to do. A calculated column is best when you want a visible status value such as Yes, No, Active, Expired, or In Range. A list validation formula is better when you want to prevent bad data from being saved, such as an end date earlier than the start date. Power Automate is better when the result should trigger an email, approval, task creation, Teams notification, or record update.

Use a calculated column when:

• You want users to see the result directly in the list view.
• You need simple status reporting based on existing columns.
• You want to group or filter items by a derived date status.

Use list validation when:

• You want to stop users from saving invalid date ranges.
• You need a clear error message at data-entry time.
• You want to enforce that StartDate must be before or equal to EndDate.

Use Power Automate when:

• You need actions, not just display output.
• You want reminders before a date window opens or closes.
• You need cross-system updates based on date status.

In practice, advanced solutions often combine all three. For example, a validation rule ensures the end date is not earlier than the start date, a calculated column displays whether the item is currently active, and a Power Automate flow sends notifications three days before expiration.

Testing strategy for reliable results

Before rolling your formula into production, build a small test list or temporary view with at least five records: one where the target date is before the range, one equal to the start date, one inside the range, one equal to the end date, and one after the range. This set gives you a quick pass-fail matrix for every boundary mode. If your results are not what you expect, the problem is usually one of these: wrong operators, time values hidden inside a date-time field, or column names typed incorrectly.

Another useful practice is to record your intended rule in plain language next to the formula in your internal documentation. Something as simple as “TargetDate counts as valid on both the first and last day of the period” can prevent future confusion when another administrator inherits the list.

Authoritative references for date standards and calendar logic

For deeper background on date representation, calendar systems, and official time references, these authoritative resources are useful:

• NIST Time and Frequency Division
• U.S. Census Bureau glossary and date-related demographic reference material
• U.S. Naval Observatory calendar and astronomical date FAQ

While these sources are not SharePoint documentation, they are valuable for understanding the date and calendar foundations behind digital systems. In enterprise administration, that grounding helps when you are troubleshooting edge cases involving date interpretation, leap years, and boundary logic.

Final best-practice recommendation

If your goal is simply to determine whether one SharePoint Online list date is between two others, start with the inclusive formula and test it against sample items. Inclusive logic is the most intuitive for most users and the safest default for scheduling and validity windows. Then switch to exclusive or hybrid boundary rules only when your process explicitly requires them. Keep column names clean, test equality cases, document the rule in plain English, and avoid making assumptions about blank dates.

The calculator on this page is designed to make that process much faster. Use it to validate the date logic, preview a ready-to-adapt formula, and visualize where your target date sits within the interval. Once the logic is correct here, moving it into a SharePoint Online calculated column becomes straightforward and much less error-prone.