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

js
with(info)
with(info, options)

Parameters

info

An object containing at least one of the properties recognized by Temporal.ZonedDateTime.from() (except calendar): day, era and eraYear, 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 of month or monthCode, and one of era and eraYear or year, 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 or undefined.
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()

js
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:

js
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:

js
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:

js
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:

js
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

See also