Handling ambiguous local times during DST transitions in Eleventy date filters

Direct pattern

Do not use Eleventy’s built-in date filter or the native JavaScript Date constructor for regional wall times. Add a custom filter that parses the input with an explicit IANA time zone using Luxon, then converts to UTC. Force the build environment to UTC and never rely on the host’s local zone.

// .eleventy.js
const { DateTime } = require('luxon');

eleventyConfig.addFilter('toUtc', (value, zone) => {
  if (!value) return '';
  const z = zone || 'UTC';
  // Parse as a local wall time in the given zone, then normalize
  const dt = DateTime.fromISO(value, { zone: z, setZone: true });
  if (!dt.isValid) return '';
  return dt.toUTC().toISO();
});

Use it with an explicit source zone: {{ "2026-11-01T01:30:00" | toUtc: "America/New_York" }}. If the source string already contains an offset, pass UTC as the zone or parse without a zone.

Confirmed facts

• Eleventy’s core date filter ultimately relies on JavaScript Date, which interprets ambiguous strings in the runtime’s local time zone. Output therefore varies with the build machine.
• JavaScript Date has no built-in DST disambiguation. Overlap and gap times are resolved by the host implementation.
• A custom Eleventy filter can wrap Luxon. Luxon uses the IANA tz database and allows an explicit zone to be supplied at parse time.
• Setting TZ=UTC for the build process removes host-dependent variation for any code that still falls back to local time.

Likely explanation and uncertainty

Luxon’s DateTime.fromISO with a zone option will resolve a wall time to an instant using the zone’s rules. For an overlap hour, Luxon’s default is to pick the earlier offset. That is the likely behavior, but the exact disambiguation strategy is implementation-dependent and can change with Luxon versions and tzdata. If you need to choose the first or second occurrence explicitly, you must supply an offset in the input string or add additional logic.

Time zone data is also version-dependent. An outdated tzdata package on CI can produce different UTC results than a developer machine even with the same code.

Steps for this case

1. Standardize inputs. Require ISO-8601 strings and always pass the originating IANA zone to the filter.
2. Replace native Date parsing in templates with the custom toUtc filter.
3. Pin the build environment: run Eleventy with TZ=UTC and keep the tz database current.
4. Verify determinism by building twice with different host zones and comparing output.

Verification:

node -e "console.log(new Date('2026-10-30T01:30:00-05:00').toISOString())"

One missing diagnostic that changes the recommendation: are your source strings naive local wall times without offset, e.g. 2026-11-01 01:30, or ISO strings that already include an offset? The disambiguation approach differs for the two cases.