Temporal.ZonedDateTime.prototype.with()
Limited availability
This feature is not Baseline because it does not work in some of the most widely-used browsers.
Experimental: This is an experimental technology
Check the Browser compatibility table carefully before using this in production.
The with()
method of Temporal.ZonedDateTime
instances returns a new Temporal.ZonedDateTime
object representing this date-time with some fields replaced by new values. Because all Temporal
objects are designed to be immutable, this method essentially functions as the setter for the date-time's fields.
To replace the calendarId
property, use the withCalendar()
method. To replace the timeZoneId
property, use the withTimeZone()
method.
Syntax
with(info)
with(info, options)
Parameters
info
-
An object containing at least one of the properties recognized by
Temporal.ZonedDateTime.from()
(exceptcalendar
):day
,era
anderaYear
,hour
,microsecond
,millisecond
,minute
,month
,monthCode
,nanosecond
,offset
,second
,year
. Unspecified properties use the values from the original date-time. You only need to provide one ofmonth
ormonthCode
, and one ofera
anderaYear
oryear
, and the other will be updated accordingly. options
Optional-
An object containing some or all of the following properties (in the order they are retrieved and validated):
disambiguation
Optional-
What to do if the local date-time is ambiguous in the given time zone (there are more than one instants with such local time, or the local time does not exist). Possible values are
"compatible"
,"earlier"
,"later"
, and"reject"
. Defaults to"compatible"
. For more information about these values, see ambiguity and gaps from local time to UTC time. offset
Optional-
What to do if the offset is explicitly provided in
info
but the offset is invalid for the given time zone in the given local time. Possible values are"use"
,"ignore"
,"reject"
, and"prefer"
. Defaults to"prefer"
. For more information about these values, see offset ambiguity. overflow
Optional-
A string specifying the behavior when a date component is out of range (when using the object
info
). Possible values are:"constrain"
(default)-
The date component is clamped to the valid range.
"reject"
-
A
RangeError
is thrown if the date component is out of range.
Return value
A new Temporal.ZonedDateTime
object, where the fields specified in info
that are not undefined
are replaced by the corresponding values, and the rest of the fields are copied from the original date-time.
Exceptions
TypeError
-
Thrown in one of the following cases:
info
is not an object.options
is not an object orundefined
.
RangeError
-
Thrown in one of the following cases:
- The provided properties that specify the same component are inconsistent.
- The provided non-numerical properties are not valid; for example, if
monthCode
is never a valid month code in this calendar. - The provided numerical properties are out of range, and
options.overflow
is set to"reject"
.
Examples
Using with()
const zdt = Temporal.ZonedDateTime.from(
"2021-07-01T12:34:56[America/New_York]",
);
const newZDT = zdt.with({ hour: 13 });
console.log(newZDT.toString()); // "2021-07-01T13:34:56-04:00[America/New_York]"
For more examples, see the documentation for the individual properties that can be set using with()
.
Offset during date changes
By default, the offset
option is set to "prefer"
, which means we use the original offset (or that provided in info
) if it's valid, and recalculate otherwise. This means if you set to another date that has a different offset due to a DST transition, the offset will be recalculated:
const zdt = Temporal.ZonedDateTime.from(
"2021-07-01T12:00:00-04:00[America/New_York]",
);
const newZDT = zdt.with({ month: 12 });
// The offset is recalculated to -05:00
console.log(newZDT.toString()); // "2021-12-01T12:00:00-05:00[America/New_York]"
And if you set the time to within the DST transition, the offset is used to resolve the ambiguity:
const zdt = Temporal.ZonedDateTime.from(
"2024-11-02T01:05:00-04:00[America/New_York]",
);
const newZDT = zdt.with({ day: 3 });
console.log(newZDT.toString()); // "2024-11-03T01:05:00-04:00[America/New_York]"
const zdt2 = Temporal.ZonedDateTime.from(
"2024-11-04T01:05:00-05:00[America/New_York]",
);
const newZDT2 = zdt2.with({ day: 3 });
console.log(newZDT2.toString()); // "2024-11-03T01:05:00-05:00[America/New_York]"
If you use offset: "use"
, then the offset will be used as-is to obtain the exact time first, and then recalculate the offset:
const zdt = Temporal.ZonedDateTime.from(
"2021-07-01T12:00:00-04:00[America/New_York]",
);
const newZDT = zdt.with({ month: 12 }, { offset: "use" });
// The offset is recalculated to -05:00, but the wall-clock time changes
console.log(newZDT.toString()); // "2021-12-01T11:00:00-05:00[America/New_York]"
You can also set offset: "reject"
to throw an error if the original offset is invalid, forcing an explicit new offset to be specified:
const zdt = Temporal.ZonedDateTime.from(
"2021-07-01T12:00:00-04:00[America/New_York]",
);
zdt.with({ month: 12 }, { offset: "reject" });
// RangeError: date-time can't be represented in the given time zone
zdt.with({ month: 12, offset: "-05:00" }, { offset: "reject" }).toString();
// "2021-12-01T12:00:00-05:00[America/New_York]"
Specifications
Specification |
---|
Temporal proposal # sec-temporal.zoneddatetime.prototype.with |
Browser compatibility
BCD tables only load in the browser