Validating Dates and Date Comparisons in Laravel

When you validate dates submitted to a Laravel request, check that each value is a valid date and that related dates appear in the required order. Laravel’s comparison rules parse date and time values before comparing them, so Laravel compares the dates and times the strings represent, not their alphabetical order.

A comparison rule sets the required order: before and after require one date to be strictly earlier or later, while before_or_equal and after_or_equal also accept dates that are equal. The input’s format, time, and timezone affect what Laravel parses and therefore what it compares.

What the four comparison rules mean

Laravel maps the four rules to ordinary date-and-time comparisons. The candidate is the date value Laravel is checking. The reference is the date it compares against, either a specific date or the value of another field.

The strict rules reject equal values. The _or_equal rules accept them. Laravel’s validation documentation describes these rules and shows comparisons between fields.

For example, this rule set requires the finish date to come after the start date:

$rules = [
    'start_date' => ['required', 'date'],
    'finish_date' => ['required', 'date', 'after:start_date'],
];

To allow both fields to have the same date and time, replace after:start_date with after_or_equal:start_date. The same distinction applies to before and before_or_equal.

Laravel parses dates before comparing them

Laravel parses comparison values as dates and times before comparing them, rather than comparing the text one character at a time. Its documentation describes date comparisons in terms of PHP’s strtotime parsing. PHP’s strtotime function turns English date-and-time descriptions into timestamps, which represent points in time.

Two values written differently compare as equal when they represent the same date and time. Two values on the same calendar day compare as different when their times differ. For example, a value at 9 a.m. is earlier than one at 5 p.m. on that same day.

The date rule checks that an input is a valid date, not a relative expression such as tomorrow, under Laravel’s documented parsing behavior. Pair it with a comparison rule when the submitted value must be a date and must also meet an ordering condition. Laravel advises using either date or date_format for a field, rather than both.

References can be another field or a relative date

A comparison rule can refer to another validated field, as in after:start_date. It can also use a date expression such as after:tomorrow, which Laravel documents as a supported reference.

These references work differently. Another field’s value comes from the request. A relative expression such as tomorrow depends on the time and timezone PHP uses to parse it, so its meaning changes over time. Use an explicit date or a concrete date object through Laravel’s fluent date-rule builder when the comparison needs a fixed reference.

In Laravel 13.x, the comparison implementation first tries to parse the rule’s reference as a date; if parsing fails, it looks for a field with that name. The documented cross-field form, such as after:start_date, is the intended way to compare request fields.

Use date_format when the input format is fixed

Use date_format when the request must follow a particular format, such as a date-time string with a known layout. Laravel then has a format to use when interpreting the candidate value. In Laravel 13.x, the comparison uses the candidate field’s format when that field has a date_format rule. It can also use the reference field’s format, or use the candidate’s format if the reference has none.

For example, if a form accepts a fixed date format, define that format with date_format and add the appropriate comparison rule. Do not also add date to the same field. The exact format must match the submitted input, or validation will fail before the comparison can pass.

Account for timezones and time values

Laravel’s date comparisons include the parsed time when the input provides one. They do not automatically mean “compare calendar days only.” If the business rule concerns only dates, accept and validate date-only values. If it concerns moments in time, include time and timezone information consistently.

PHP uses the default timezone when an input does not specify one, and it interprets relative expressions against a current-time base. Laravel does not impose one universal timezone policy for every comparison. Choose a consistent timezone for submitted values and references, and make timezone information explicit when values come from different zones.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com