Open Bug 2013444 Opened 5 months ago Updated 28 days ago

Date parser can't handle ISO 8601 short (hours-only) offset with T separator (not space)

Categories

(Core :: JavaScript Engine, defect, P3)

Product:
Core
Component:
JavaScript Engine
Version:
Firefox 146
Type:
defect

Tracking

()

People

(Reporter: adamw, Unassigned)

References

(Blocks 1 open bug)

Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:146.0) Gecko/20100101 Firefox/146.0

Steps to reproduce:

Entered new Date("2026-01-29T12:57:49.112827-08") at the console

Actual results:

Invalid Date

Expected results:

Date Thu Jan 29 2026 12:57:49 GMT-0800 (Pacific Standard Time)

Support for the hours-only offset format was added in https://bugzilla.mozilla.org/show_bug.cgi?id=1328672 , but it seems to not work if the date string also contains mi

Summary: Date parser can't handle short (hours-only) offset combined with microseconds → Date parser can't handle ISO 8601 short (hours-only) offset with T separator (not space)

D'oh, sorry for the short comment - worked out while filing that the issue wasn't quite what I thought it was.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1328672 the date parser got support for hours-only offsets, but it seems to work only if the separator between date and time is a space, not if it's the character T. So this works:

new Date("2026-01-29 12:57:49.112827-08")

And this also works:

new Date("2026-01-29T12:57:49.112827-08:00")

but this is NaN:

new Date("2026-01-29T12:57:49.112827-08")

This broke https://github.com/cockpit-project/cockpit 's PackageKit backend in an interesting way, which I'm currently bodging downstream.

Interestingly, Chromium's parser has precisely the same issue, I'll file it there too.

To be fair, the ECMA spec does not actually require implementations to parse this format:
https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-date-time-string-format
it defines the offset format as:
"the UTC offset representation specified as "Z" (for UTC with no offset) or as either "+" or "-" followed by a time expression HH:mm (a subset of the time zone offset string format for indicating local time ahead of or behind UTC, respectively) "
i.e. it specifically acknowledges it's only allowing a subset of ISO 8601.

However, in practice, I think it's pretty common for folks to assume/expect that a JS date parser will handle any ISO 8601 string, and it seems like a good idea to support this.

JavaScriptCore and V8 agree with SpiderMonkey's behavior; they rejects the format and returns Invalid Date.
XS and GraalJS accepts the format.
QuickJS supports the format, but not the "2026-01-29 12:57:49.112827-08" format.
Boa doesn't accept any of them.

Then, given that major browsers agree on rejecting the format, supporting it in SpiderMonkey will result in another compatibility issue,
unless all of them starts supporting the format at the same time.

I reported the same issue to Chromium (V8) - https://issues.chromium.org/issues/479862357 .

Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: -- → S4
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.