Proposal-temporal: Should Absolute#getEpochSeconds/getEpochMilliseconds return Number or BigInt?

[Ms2ger]

Looks like the spec and the polyfill currently disagree. I have no strong opinion on which one to pick.

[ryzokuken]

On one hand, Number allows us to interoperate with Date, but then BigInt is more consistent with the behavior for epochnanos.

[jasonwilliams]

It would make sense to keep as number considering the interoperability with other libraries (moment.js etc), external APIs and legacy Date.

https://momentjs.com/docs/#/parsing/unix-timestamp-milliseconds/
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/setSeconds
https://date-fns.org/v2.10.0/docs/set#syntax

if interoperability isn't something we're too bothered with (_why would an app use both moment and Temporal side by side?_) then bigInt would be nice

[ryzokuken]

@sffc @pipobscure @gibson042 @ljharb @ptomato thoughts?

[ptomato]

Since we've decided to give Absolute the same range as legacy Date (epoch ± 1e8 days), it's not possible for these methods to return numbers that are beyond Number.MAX_SAFE_INTEGER. So I think Numbers should be used for these. In my opinion BigInt should only be used in places where unsafe integers are possible values.

[pipobscure]

The way this was intended was epochSeconds & epochMilliseconds to return numbers (since the range is fine) and epochMicroseconds & epochNanoseconds to return BigInt for the improved range.

The lower precision ones should return numbers also for interoperability with Legacy-Date while the higher precision ones are free to use the improved range.

[jasonwilliams]

The way this was intended was epochSeconds & epochMilliseconds to return numbers (since the range is fine) and epochMicroseconds & epochNanoseconds to return BigInt for the improved range.

I think we have consensus on this @ryzokuken