Helping fix Temporal
GMT is built on Temporal, the new JavaScript date and
time standard. Until browsers and Node ship Temporal natively, GMT runs on the community
@js-temporal/polyfill.
If you use GMT, there is nothing on this page for you to do. The polyfill has a handful of bugs in rare corners of the calendar. GMT spots each one and gives you the right answer anyway. The rest of this page is the detail: which bugs, and what we have done to get them fixed for everyone.
We test GMT against the Temporal standard itself, never against the polyfill, so we can see when the polyfill is wrong. When it is, we send the fix to the people who maintain the polyfill, and to the Temporal standard’s own reference code where the same bug lives there too.
Which bugs GMT still works around
Section titled “Which bugs GMT still works around”Each row is one bug in the polyfill, together with the code GMT runs instead so that you still get the right answer.
The middle column says whether GMT still needs that code. GMT includes a small test for each bug and runs it against the polyfill version it depends on; the numbers are what those tests returned when this page was built. When the polyfill fixes a bug, the row changes on its own.
| What GMT works around | Still needed? | What we sent |
|---|---|---|
| D1 Dates within about a year of the earliest or latest date Temporal can represent, in the non-ISO calendars | ✓ Yes 23 of 27 checks fail | |
| D2 Buddhist calendar dates before 1582, read through an old Julian/Gregorian switch | ✓ Yes 2 of 2 checks fail | — |
| D3 + D4 Hebrew calendar years at or before year 0 | ✓ Yes 3 of 3 checks fail | — |
| D5 Indian national calendar dates before ISO year 1 | ✓ Yes 1 of 1 checks fail | — |
| D6 Counting months between two dates in a non-ISO calendar, at the end of a month | ✓ Yes 11 of 11 checks fail | — |
| D7 Counting years from a leap-month date in the Hebrew calendar | ✓ Yes 2 of 2 checks fail | — |
| D8 Japanese era codes, and the date the Meiji era starts | ✓ Yes 3 of 3 checks fail | |
| D10 Coptic and Ethiopic dates in far years, where a short thirteenth month can be skipped | No 2 of 2 checks pass | — |
| D11 Rounding or measuring a span in months from the 29th, 30th or 31st | ✓ Yes 6 of 6 checks fail | |
| D12 Zoned strings whose offset is written with seconds, in a zone whose offset was not a whole number of minutes | ✓ Yes 2 of 2 checks fail | — |
| D13 Finding a zone's clock changes, and the start or length of a day, where two changes fall less than 14 days apart | ✓ Yes 6 of 8 checks fail | — |
| D9 Adding or counting very large numbers of months in a non-ISO calendar | ✓ Yes 4 of 4 checks fail | — |
| zoned.A Zoned times within a day of the earliest or latest instant Temporal supports | ✓ Yes 10 of 10 checks fail | |
| zoned.B Finding the next time zone transition within about two months of the latest instant | ✓ Yes 3 of 3 checks fail | |
| zoned.E Time zone transitions before 1847, including the 1844 date-line move in Asia/Manila and four Pacific zones | ✓ Yes 5 of 5 checks fail | |
| zoned.D A calculation in UTC near the range limit that should be rejected, but quietly returned a value | ✓ Yes 2 of 2 checks fail |
Still needed? shows what GMT’s own tests for that bug returned against the polyfill version it depends on. A dash under What we sent means we had nothing to send: either someone had already fixed the bug, or it cannot reach anyone using GMT.
How a fix reaches you
Section titled “How a fix reaches you”The polyfill is being brought back in line with the current version of the standard, one change at a time. It is a long job, and it decides where each fix has to go:
- The standard first. Its maintainers asked us to send fixes to the Temporal standard rather than straight to the polyfill, so that the catching-up work stays manageable.
- The polyfill next. Fixes arrive there as that work moves forward. This is why several of the pull requests below were closed with thanks instead of merged. None was turned down; each was sent where it would do more good.
- A release last. The maintainers would rather publish one release once the polyfill has caught up than a release for each fix.
Until that release, GMT’s own code covers every bug in the table above.
What we sent, and what happened to it
Section titled “What we sent, and what happened to it”Sometimes a fix is already written and waiting, and another pull request would only add noise. What helps then is evidence: a way to reproduce the bug, and measurements of what the pending fix changes. Those are listed here too, marked as someone else’s work.
So far we have sent 11 reports and fixes to the Temporal projects, 6 of them as ready-to-merge code changes, and added the evidence to one more the maintainers had already written. GMT already gives you the correct answer for every one of them: 11 through its own built-in fix, and 1 because the bug is in code GMT doesn't use.
js-temporal/temporal-polyfill
| Filing | In GMT | The problem | Kind | Upstream status | Replies | Last activity |
|---|---|---|---|---|---|---|
| #361 | ✓ Already handled | April 2026 rebase, part 3 Rounding or measuring a span in months from the 29th, 30th or 31st can answer against the wrong pair of dates, because the polyfill never rechecks that the window it searched contains the date it is aiming for. The maintainer had already written this fix, so rather than file a duplicate we added what it was missing: a way to reproduce the bug, a scan of Chromium 153 against the published release, and before-and-after measurements of the fix applied on main. | Pull request Port Theirs — we added evidence | Merged, not yet in a published release | 0 | 2026-09-21 |
| #367 | ✓ Already handled | Validate result in UTC fast path in GetPossibleEpochNanoseconds Near the end of the supported range, a calculation in the UTC time zone quietly returns a wrong value where it should report an error. The shortcut the code takes for UTC skips the range check that every other time zone goes through. | Pull request Port | Closed Closed, not rejected: the maintainer is applying the upstream changes in order and asked to keep it that way, so this one arrives in its turn rather than ahead of it. | 1 | 2026-09-21 |
| #368 | ✓ Already handled | Update Meiji era start date The Japanese calendar puts dates from 1868 to the end of 1872 in the Meiji era, where the standard asks for the Gregorian-equivalent era. The era and era-year are wrong for those five years. | Pull request Port | Closed Closed, not rejected: the maintainer is applying the upstream changes in order and asked to keep it that way, so this one arrives in its turn rather than ahead of it. | 1 | 2026-09-21 |
| #369 | ✓ Already handled | Fix extreme PlainYearMonth crash in non-ISO calendars Converting a Hebrew, Islamic, Coptic-family or Indian calendar date near either end of the supported range fails with an Invalid ISO date error, even though the date asked for is a real one. | Pull request Port | Closed Closed, not rejected: the maintainer is applying the upstream changes in order and asked to keep it that way, so this one arrives in its turn rather than ahead of it. | 1 | 2026-09-21 |
| #370 | ✓ Already handled | Don't format dates past the range limit when counting months in until() Counting months between two dates in a non-ISO calendar fails when the later date falls in the first or last month of the supported range. The month-by-month loop builds a date beyond the range that it never actually needs. Same fix: tc39 #3327 Depends on: polyfill #369 | Pull request Fix | Closed Closed, not rejected: the maintainer will apply the fix to the Temporal standard first, and it reaches the polyfill from there. | 1 | 2026-09-21 |
| #371 | ✓ Already handled | Search the last partial window when looking for the next time zone transition Looking for the next time zone transition in roughly the last two months of the supported range can report that there is none, when there is one. startOfDay, hoursInDay and toZonedDateTime then fail instead of returning an answer. Same fix: tc39 #3328 | Pull request Fix | Closed Closed, not rejected: the maintainer will apply the fix to the Temporal standard first, and it reaches the polyfill from there. | 1 | 2026-09-21 |
| #372 | ✓ Already handled | Start the time zone transition search before the first transition in 1844 Time zone lookups before 1847 miss a real transition on 31 December 1844 in five zones: Asia/Manila and four Pacific zones. The search starts at 1847, which used to be the earliest transition anyone had recorded and no longer is. Same fix: tc39 #3330 | Pull request Fix | Closed Closed, not rejected: the maintainer will apply the fix to the Temporal standard first, and it reaches the polyfill from there. | 1 | 2026-09-21 |
| #373 | ✓ Already handled | Release request: main has fixes that 0.5.1 doesn't (ZonedDateTime near the Instant limits, #341, #347) Anyone using the published 0.5.1 release still meets several bugs that were fixed 76 commits ago on the project's main branch, among them failures for valid zoned dates near both ends of the range and two calendar-conversion bugs. No release has been published to bring those fixes to them. Closes: polyfill #341 Closes: polyfill #347 | Issue Release request | Open | 1 | 2026-09-21 |
tc39/proposal-temporal
| Filing | In GMT | The problem | Kind | Upstream status | Replies | Last activity |
|---|---|---|---|---|---|---|
| #3327 | ✓ Already handled | non-ISO until() by months gives wrong results since #3245, and throws near the range limits Counting months between two dates in a non-ISO calendar has given a wrong answer since a recent change, at ordinary dates as well as unusual ones. Adding the answer back to the first date no longer lands on the second, and near the ends of the range the count fails outright. Same fix: polyfill #370 | Issue Report | Open | 0 | 2026-09-18 |
| #3328 | ✓ Already handled | GetNamedTimeZoneNextTransition misses a transition in the last search window before the max Instant Looking for the next time zone transition in the last stretch before the end of the supported range can report that there is none, when there is one. Code that relies on the answer then fails instead of getting one. Same fix: polyfill #371 | Issue Report | Open | 0 | 2026-09-18 |
| #3329 | ✓ Doesn't affect GMT | calendarToIsoDate overshoot assertion from #3292 is reachable in coptic/ethiopic/ethioaa month 13 Building a Coptic, Ethiopic or Ethioaa date in the thirteenth month can fail an internal check instead of returning the date. The search moves eight days at a time, on the assumption that it can never step over a whole month, but that month is only five or six days long. GMT computes coptic and ethiopic dates through ethioaa and finds a date from its calendar fields by bisection, so this search-step bug can't affect it. A canary check (D10) watches for it in every polyfill release. | Issue Report | Open | 0 | 2026-09-18 |
| #3330 | ✓ Already handled | time zone transitions before 1847 are not found (Asia/Manila and four Pacific zones on 1844-12-31) Time zone lookups before 1847 miss a real transition on 31 December 1844 in five zones: Asia/Manila and four Pacific zones. The search assumes no zone has a transition before 1847, which the time zone database contradicts. Same fix: polyfill #372 | Issue Report | Open | 0 | 2026-09-19 |
Already handled: GMT gives you the correct answer today, whichever polyfill version you have installed. Doesn't affect GMT: the bug is in code GMT doesn't use. Fix filed upstream: we have written the fix and the polyfill's maintainers have it; it reaches you with the next polyfill release. Reported upstream: we sent the maintainers the bug and a way to reproduce it. A row markedTheirs is a report someone else opened, where our part was the evidence rather than the fix. Each closed row says why it closed: so far every one was closed because the fix was going somewhere better, not because it was turned down. We read each report's state from GitHub every time this site is built (last checked 2026-09-22 18:44 UTC, from the saved copy). Repliescounts comments from the project's maintainers and other users.
What this means for you
Section titled “What this means for you”You don’t need to do anything. Where the polyfill has one of these bugs, GMT uses its own correct code instead. It checks once, as it loads, whether the installed polyfill still has each bug; where the bug is gone, GMT uses the polyfill directly. You get the same correct answer either way.
So when a polyfill release carries these fixes, GMT’s extra code simply stops being used. Your results don’t change, which is the point: there is nothing here for you to keep track of.
These checks run on their own, so nobody has to remember them. Every bug on this page has a test that runs against the installed polyfill, and GMT’s answers are compared with the Temporal built into Chrome — date by date, across every calendar GMT supports. For GMT 1.18.0 that comparison found no differences.
What kind of bugs are these?
Section titled “What kind of bugs are these?”They’re rare edge cases. Most only show up:
- near the very first or very last date Temporal can represent (around the year 275,000);
- in non-Gregorian calendars, such as Hebrew, Persian, Islamic or Japanese; or
- in time zone history from before the 1850s.
Temporal is a large, carefully designed standard, and the polyfill is a big piece of work. Finding bugs like these is normal. We found them because GMT tests the unusual corners that most code never reaches.
We sent them to two places:
- The polyfill (
js-temporal/temporal-polyfill), the package GMT and many other projects install. Some of its fixes are already written but not yet in a published release, so we’ve asked for a new release. That would also fix two bugs other users had already reported. - The Temporal proposal (
tc39/proposal-temporal), which has its own reference copy of the same code. Where a bug exists there too, we reported it with the same fix, so it’s corrected at the source.
How we check each fix
Section titled “How we check each fix”- The correct answer comes from the Temporal standard, its official test suite (test262) and the Temporal built into Chrome. We never use the polyfill’s own answer as the reference.
- Each fix is tested on a real build of the polyfill, with and without the change, using the exact example in the report.
- We also check that the fix doesn’t change any answer that was already right.
Every example and fix is written up in full in GMT’s repository:
js-temporal-polyfill-bugs.md.
See also: Why GMT? · Correct at the edges · Standards