Range

Warning: You are browsing the documentation for Symfony 5.x, which is no longer maintained.

Read the updated version of this page for Symfony 7.2 (the current stable version).

Validates that a given number or DateTime object is between some minimum and maximum.

Applies to property or method
Class Range
Validator RangeValidator

Basic Usage

To verify that the height field of a class is between 120 and 180, you might add the following:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// src/Entity/Participant.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Participant
{
    /**
     * @Assert\Range(
     *      min = 120,
     *      max = 180,
     *      notInRangeMessage = "You must be between {{ min }}cm and {{ max }}cm tall to enter",
     * )
     */
    protected $height;
}

Date Ranges

This constraint can be used to compare DateTime objects against date ranges. The minimum and maximum date of the range should be given as any date string accepted by the DateTime constructor. For example, you could check that a date must lie within the current year like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/Entity/Event.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Event
{
    /**
     * @Assert\Range(
     *      min = "first day of January",
     *      max = "first day of January next year"
     * )
     */
    protected $startDate;
}

Be aware that PHP will use the server's configured timezone to interpret these dates. If you want to fix the timezone, append it to the date string:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/Entity/Event.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Event
{
    /**
     * @Assert\Range(
     *      min = "first day of January UTC",
     *      max = "first day of January next year UTC"
     * )
     */
    protected $startDate;
}

The DateTime class also accepts relative dates or times. For example, you can check that a delivery date starts within the next five hours like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
// src/Entity/Order.php
namespace App\Entity;

use Symfony\Component\Validator\Constraints as Assert;

class Order
{
    /**
     * @Assert\Range(
     *      min = "now",
     *      max = "+5 hours"
     * )
     */
    protected $deliveryDate;
}

Options

groups

type: array | string default: null

It defines the validation group or groups of this constraint. Read more about validation groups.

invalidDateTimeMessage

type: string default: This value should be a valid number.

5.2

The invalidDateTimeMessage option was introduced in Symfony 5.2.

The message displayed when the min and max values are PHP datetimes but the given value is not.

You can use the following parameters in this message:

Parameter Description
{{ value }} The current (invalid) value

invalidMessage

type: string default: This value should be a valid number.

The message displayed when the min and max values are numeric (per the is_numeric PHP function) but the given value is not.

You can use the following parameters in this message:

Parameter Description
{{ value }} The current (invalid) value
{{ label }} Corresponding form field label

5.2

The {{ label }} parameter was introduced in Symfony 5.2.

max

type: number or string (date format)

This required option is the "max" value. Validation will fail if the given value is greater than this max value.

maxMessage

type: string default: This value should be {{ limit }} or less.

The message that will be shown if the underlying value is more than the max option, and no min option has been defined (if both are defined, use notInRangeMessage).

You can use the following parameters in this message:

Parameter Description
{{ limit }} The upper limit
{{ value }} The current (invalid) value

maxPropertyPath

type: string

It defines the object property whose value is used as max option.

For example, if you want to compare the $submittedDate property of some object with regard to the $deadline property of the same object, use maxPropertyPath="deadline" in the range constraint of $submittedDate.

Tip

When using this option, its value is available in error messages as the {{ max_limit_path }} placeholder. Although it's not intended to include it in the error messages displayed to end users, it's useful when using APIs for doing any mapping logic on client-side.

min

type: number or string (date format)

This required option is the "min" value. Validation will fail if the given value is less than this min value.

minMessage

type: string default: This value should be {{ limit }} or more.

The message that will be shown if the underlying value is less than the min option, and no max option has been defined (if both are defined, use notInRangeMessage).

You can use the following parameters in this message:

Parameter Description
{{ limit }} The lower limit
{{ value }} The current (invalid) value

minPropertyPath

type: string

It defines the object property whose value is used as min option.

For example, if you want to compare the $endDate property of some object with regard to the $startDate property of the same object, use minPropertyPath="startDate" in the range constraint of $endDate.

Tip

When using this option, its value is available in error messages as the {{ min_limit_path }} placeholder. Although it's not intended to include it in the error messages displayed to end users, it's useful when using APIs for doing any mapping logic on client-side.

notInRangeMessage

type: string default: This value should be between {{ min }} and {{ max }}.

The message that will be shown if the underlying value is less than the min option or greater than the max option.

You can use the following parameters in this message:

Parameter Description
{{ max }} The upper limit
{{ min }} The lower limit
{{ value }} The current (invalid) value

payload

type: mixed default: null

This option can be used to attach arbitrary domain-specific data to a constraint. The configured payload is not used by the Validator component, but its processing is completely up to you.

For example, you may want to use several error levels to present failed constraints differently in the front-end depending on the severity of the error.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version