`.getNextDateFrom()` fails when `Intl` resolves timezone to `Etc/Unknown` on Chromium-based Browser in Linux OS

Description

.getNextDateFrom() can fail in Chromium-based browser environments on Linux when the runtime resolves the system timezone to Etc/Unknown.

When CronTime is created without an explicit timeZone or utcOffset, it relies on the system timezone returned by:

Intl.DateTimeFormat().resolvedOptions().timeZone

In some Chromium-based browsers on Linux, this value can be returned as:

"Etc/Unknown"

This is not a valid timezone for Luxon. As a result, when .getNextDateFrom() tries to calculate the next execution date, the internal DateTime becomes invalid and the method eventually throws:

ERROR: You specified an invalid date.

Reproduction

import { CronTime } from 'cron';

const cronTime = new CronTime('* * * * *');

cronTime.getNextDateFrom(new Date());

In an affected Chromium-based browser environment on Linux where:

Intl.DateTimeFormat().resolvedOptions().timeZone

returns:

"Etc/Unknown"

the call to .getNextDateFrom() fails.

Expected Behavior

.getNextDateFrom() should be able to calculate the next execution date successfully.

If the automatically resolved system timezone is invalid or unsupported, cron should handle it gracefully instead of passing the invalid value directly to Luxon.

Possible fallback behavior could include:

• validating the resolved timezone before using it;
• falling back to the local UTC offset;
• falling back to UTC;
• or avoiding automatic timezone assignment when the resolved value is invalid.

Actual Behavior

.getNextDateFrom() throws an invalid date error because the auto-detected timezone is invalid:

ERROR: You specified an invalid date.

Root Cause

The issue appears to happen because CronTime trusts the value returned by:

Intl.DateTimeFormat().resolvedOptions().timeZone

without validating whether it is a valid IANA timezone.

In affected Chromium-based browser environments on Linux, this value can be Etc/Unknown. Once this invalid timezone is used by Luxon, the generated date becomes invalid, which causes .getNextDateFrom() to fail.

Why this matters

This makes cron scheduling fail in browser or extension environments even when the cron expression itself is valid.

For example, a simple expression such as:

'* * * * *'

can fail only because the runtime-provided timezone is invalid.

Suggested Fix (1)

Before using the timezone returned by Intl.DateTimeFormat().resolvedOptions().timeZone, validate that it is supported.

If the resolved timezone is invalid, CronTime should use a safe fallback instead of passing the invalid timezone to Luxon.

For example:

const resolvedTimeZone = Intl.DateTimeFormat().resolvedOptions().timeZone;

if (resolvedTimeZone && DateTime.local().setZone(resolvedTimeZone).isValid) {
  // use resolvedTimeZone
} else {
  // fall back to UTC, local offset, or no explicit timezone
}

This would prevent .getNextDateFrom() from throwing when the browser returns Etc/Unknown.

Suggested Fix (2)

Detect and Set the utcOffset for timezone setting instead of using Intl.DateTimeFormat().resolvedOptions().timeZone.

Environment

Observed in:

OS: Linux 7.1 / X11 / 64-bit
Browser: Chromium-based browser (e.g. Brave)
Runtime: browser / extension environment
Resolved timezone: `Etc/Unknown`
Affected method: `.getNextDateFrom()`

Related

Downstream project: https://github.com/scriptscat/scriptcat/

• Issue 1: https://github.com/scriptscat/scriptcat/issues/1326
• Issue 2: https://github.com/scriptscat/scriptcat/discussions/1530
• Workaround: https://github.com/scriptscat/scriptcat/pull/1531

Chromium Issue: https://support.google.com/chrome/thread/230621092/chrome-version-116-displaying-wrong-timezone-on-linux-computers?hl=en