The quick answer
Keep the original Date instant. Use format.format with DATETIME and format.Timezone.AMERICA_NEW_YORK to render it as Eastern time. Adding three hours changes the timestamp; it does not format the same moment in another timezone.
A forum author wanted Eastern time from a scheduled script and proposed setHours(getHours()+3). This walkthrough separates that arithmetic from display formatting. It runs actual JavaScript in a local Pacific Node process and executes a SuiteScript 2.1 helper through an explicit Intl-backed N/format shim. The shim's fixed en-US layout is not evidence of native formatting parity. No account script, deployment, upload or record save occurs.
Before you start
The fixed summer instant is 2026-07-01T16:00:00.000Z, epoch 1782921600000. It displays as 9 AM in Los Angeles and noon in New York in the local formatter. The input includes Z, so it identifies a UTC instant unambiguously.
The helper is a module example for an appropriate SuiteScript execution context. The local harness controls its Node process timezone, America/Los_Angeles, and replaces N/format with Intl. It does not change the machine clock or an account timezone. A local Node test does not establish the runtime defaults of a deployed scheduled script.
01. Identify the helper
Search the local File Cabinet for east_coast_clock.js, file 940. The list supplies fictional sample code-file identity using an existing native-style surface. It does not demonstrate a real upload, installed script or scheduled deployment.
02. Observe what adding three hours changes
The deliberately wrong local command executes this actual expression:
const date = new Date(iso);
date.setHours(date.getHours() + 3);
setHours mutates the Date using the runtime's local calendar components. It is not a timezone-label operation. ECMAScript: Date.prototype.setHours
Read back the result: 16:00Z becomes 19:00Z, an observed change of 10800000 ms. Formatting the original instant in New York gives noon; formatting the shifted instant gives 3 PM. The local test reports Same instant: false.
If the requirement really is three elapsed hours later, that is a separate operation. For an exact duration, add milliseconds to getTime. Local calendar setters can behave differently around daylight-saving transitions.
03. Format the original instant explicitly
The corrected helper creates the original Date and passes an explicit timezone to N/format:
const instant = new Date(iso);
const text = format.format({
value: instant,
type: format.Type.DATETIME,
timezone:
format.Timezone.AMERICA_NEW_YORK
});
Oracle documents the datetime timezone parameter and the named-zone enum. Output uses the applicable formatting preferences; it is display text. The example retains the original UTC and epoch separately. Oracle: format.format, Oracle: format.Timezone
The local helper reads back 2026-07-01T16:00:00.000Z, epoch 1782921600000, and 0 ms difference. It displays 9 AM Pacific and noon Eastern through the shim's fixed layout. Input unchanged: true verifies this local path.
This is not a native format-output comparison. The shim's punctuation, spaces, date layout and twelve-hour clock are local choices. Its diagnostic offsets are computed separately with Intl, rather than promised as part of N/format's returned string.
04. Check seasonal and repeated-hour cases
Run the four-case verification. The summer example uses GMT-4 for New York; the winter example uses GMT-5. A named zone selects rules for the instant, rather than requiring a manually maintained seasonal offset.
The autumn cases are 2026-11-01T05:30Z and 2026-11-01T06:30Z. Both display 01:30 AM in New York. The first has diagnostic offset GMT-4, the second GMT-5. Their epochs differ by 3600000 ms.
Every input instant remains unchanged. The harness writes eastern_time_report.json, an actual 1070-byte UTF-8 file containing four computed cases. It records UTC, epoch, Eastern display, case label and offset; the report also retains the named timezone and explicit local scope.
05. Keep an unambiguous audit trail
Open the computed report. Compare each UTC timestamp with its Eastern display and separately computed offset. The two repeated-hour rows demonstrate why a wall-clock string alone cannot identify an event uniquely.
Download eastern_time_report.json. The capture compares its bytes exactly with the actual local file and records the same SHA-256. Retain the UTC instant or epoch and the intended named timezone when the business meaning depends on it. A rendered wall time and offset can be useful additional context.
No DATE, DATETIME or DATETIMETZ field is set here. Field binding, account display preferences, permissions and persistence require separate implementation and verification. The example also does not parse local wall times back into instants.
Common questions
Does a Date contain Eastern or Pacific time?
It represents an instant as epoch milliseconds. Local getters and setters interpret components in the runtime's local timezone; formatting can render the same instant in a chosen zone. Keep that distinction explicit.
Is Pacific always exactly three hours behind Eastern?
Do not encode that as a timezone conversion rule. The clocks change at different UTC instants on transition days, and named-zone rules can change. This example selects America/New_York directly instead of relying on a fixed difference.
Is the formatted string a new timestamp?
It is display text. The helper retains the original instant separately and verifies its epoch in the local model. Reformatting should not be confused with intentionally computing a later event.
Will my account display exactly this punctuation and clock style?
The shim uses a fixed en-US Intl layout. Native N/format uses applicable preferences and context. Use the explicit timezone enum when Eastern display is required; do not treat the shim as a native output oracle.
What if the timezone is omitted or invalid?
Oracle documents preference/context defaults and GMT fallback for an invalid timezone. This helper passes the explicit documented enum and does not test those fallback cases.
How should I interpret a local 1:30 AM string?
First establish its date, timezone and disambiguating offset or instant. Repeated hours can identify two instants; spring-forward gaps can contain nonexistent local times. Parsing requires a separate policy. This example starts with explicit UTC inputs and does not implement ambiguous-time parsing.
Can I pass the formatted string to a date-time record field?
This guide demonstrates display, not field storage. Do not infer record.setValue or persistence behavior from a formatted string or from this mock. Verify the field's supported input contract separately.
Are these timezone results permanent?
Named-zone calculations depend on the runtime's timezone-rule data for the relevant date. Test the dates and zones your application needs rather than promising identical behavior across all rule-data revisions.