Error using Temporal.ZonedDateTime.compare

[EmilyRagan]

I'm getting the following error when running my Node project on a line that uses Temporal.ZonedDateTime.compare(...)

Error: Convert JSBI instances to native numbers using `toNumber`.

Is this an issue with the current dependency version for jsbi? I see from the readme that this polyfill is expected to work with my version of Node. I do not have this problem on the browser-side portion of my project

Version of @js-temporal/polyfill: 0.5.1
Version of jsbi dependency of @js-temporal/polyfill: 4.3.2
Version of Node: 20.13.1
Version of TypeScript: 5.3.3

[12wrigja]

That error triggers here: https://github.com/GoogleChromeLabs/jsbi/blob/5382367c7e3199858d36bb620977e1f90605bcb9/lib/jsbi.ts#L81

This typically occurs when you use the native mathematical operators with JSBI instances. For example:

const x = JSBI.BigInt(10);
const y = JSBI.BigInt(11);
const z = x + z; // Oops - this doesn't work, and will trigger that error.

That being said you said you ran into this using the ZonedDateTime.compare method. That method looks into the internals of a ZonedDateTime instance to retrieve what should be a JSBI instance (here:

temporal-polyfill/lib/zoneddatetime.ts

Line 465 in f3c07e5

const ns1 = GetSlot(one, EPOCHNANOSECONDS);

).

Roughly, that value is created once and set in the constructor here:

temporal-polyfill/lib/zoneddatetime.ts

Line 26 in f3c07e5

const epochNanoseconds = ES.ToBigInt(epochNanosecondsParam);

Can you share how those ZonedDateTime instances you are comparing are being created?

[EmilyRagan]

Thanks for the reply @12wrigja!

These ZonedDateTime instances are being created from JS Date objects that were reconstituted from ISO 8601 UTC strings, in order to support existing data in my system. Is there a different/better way to support this workflow?

const date = new Date(dateString);
const zonedDateTime = Temporal.ZonedDateTime.from({
    year: date.getUTCFullYear(),
    month: date.getUTCMonth() + 1, // Months are 0-indexed in JS
    day: date.getUTCDate(),
    hour: date.getUTCHours(),
    minute: date.getUTCMinutes(),
    second: date.getUTCSeconds(),
    millisecond: date.getUTCMilliseconds(),
    timeZone: 'UTC',
})

[ptomato]

@EmilyRagan Do you have a standalone script that reproduces the problem?
I tried with the following:

import { Temporal } from './dist/index.esm.js';  // or @js-temporal/polyfill
const date = new Date('2025-06-30T10:11');
const zonedDateTime = Temporal.ZonedDateTime.from({
  year: date.getUTCFullYear(),
  month: date.getUTCMonth() + 1, // Months are 0-indexed in JS
  day: date.getUTCDate(),
  hour: date.getUTCHours(),
  minute: date.getUTCMinutes(),
  second: date.getUTCSeconds(),
  millisecond: date.getUTCMilliseconds(),
  timeZone: 'UTC'
});
Temporal.ZonedDateTime.compare(zonedDateTime, Temporal.Now.zonedDateTimeISO());

This worked for me, with all the versions exactly as you mentioned above. So I wonder if it's a particular date string that is causing the problem.

That said, there is an easier way to support that workflow, maybe it'll work around the problem for you?

const instant = Temporal.Instant.from(dateString);
const zonedDateTime = instant.toZonedDateTimeISO('UTC');

Or in case you can't avoid the JS Date objects, e.g. if they are returned from some API:

const zonedDateTime = date.toTemporalInstant().toZonedDateTimeISO('UTC');

[EmilyRagan]

@ptomato Thank you! I did not realize that the from method on Temporal.Instant would accept an ISO 8601 string. That certainly simplifies my logic. Unfortunately this doesn't seem to solve my problem. I think I have a bit more detail to share of when/how I'm running into this issue, and it is a very specific situation.

Some background context: My project is a monorepo, with front-end and back-end for the website in separate folders in the same repo. We also have some local packages in the workspace, in order to share common code between the front-end and back-end. I have placed this helper function (to convert ISO 8601 strings to Temporal ZonedDateTime) in one of these local packages. The back-end is CJS because of a particular library that is central to the project. The local packages end up needing to be built in order to be used.

I encounter this jsbi error only when all of the following are true:

1. The helper method is in the shared local package that gets built
   • This error does not occur if the helper method is defined in the back-end code
   • Changing the logic of the helper method from my original implementation above to the much simpler Temporal.Instant.from does not have any impact on the error
2. Use Temporal.ZonedDateTime.compare to compare the 2 instances
   • Using time1.until(time2) does not result in this error, and I am able to use the sign value of the resulting Temporal.Duration in the same way as the result of Temporal.ZonedDateTime.compare, this is the workaround I've been using
3. At least one of the ZonedDateTime instances are created using this helper function
   • Either instance, or both, being created by this local package helper function will result in the error

[12wrigja]

Your description is making me think that the JSBI package (or possibly the way we are using it somewhere) probably has a dual package hazard, where one version of JSBI doesn't realize that it is being handed a JSBI.BigInt from the other version.

Probably the easiest way to verify this if feasible is to step through your code in a debugger and look very carefully at the call stack when the error is being thrown, and see if you can deduce (probably from inspecting prototypes?) whether this is happening.

[EmilyRagan]

@ptomato does installing this polyfill library augment the Date object to have the .toTemporalInstant() function?

[justingrant]

@EmilyRagan IIRC, this polyfill does not currently put anything into the global namespace, to avoid conflicts with native implementations or other polyfills.

[justingrant]

Your description is making me think that the JSBI package (or possibly the way we are using it somewhere) probably has a dual package hazard, where one version of JSBI doesn't realize that it is being handed a JSBI.BigInt from the other version.

@12wrigja It's been a few years after the initial decision to use JSBI. Do you think we're ready to jettison it?

[ptomato]

this polyfill does not currently put anything into the global namespace, to avoid conflicts with native implementations or other polyfills.

Right, there's a manual step required to get the Date method

[12wrigja]

Unfortunately I think Google still needs to support browsers without native BigInt.

I wonder if we can stop shipping JSBI as part of the distributed package contents and tell anyone in the opensource ecosystem that needs the version w/ JSBI to instead do some fancy npm link-ing against the project source, and mark the relevant version of JSBI as a devDep?

[12wrigja]

(For context, at Google we don't consume the distributed artifacts published to NPM but instead roughly consume a fork of the source. It would be particularly difficult to reverse the sources to rewrite from the native BigInt source back to JSBI, so it seems one potential workaround is to leave JSBI in the sources but remove it during distribution and ensure the package.json reflects that).