Hacker News Reader

Comment by mikece | Hacker News Reader

I was going to ask a variant of that question: what is the status of BigInt and when might it clear TC39 approval? In most languages a Date object is just a BigInt with Unix time() making this somewhat obvious. BigInt will allow not only proper Date implementation but Currency and Real types, and many more things.

View on HN

If by BigInt you mean an arbitrary-precision integer type, then AFAIK no major language uses it to represent dates.

If you mean a 64-bit integer type (which, to be fair, is 11 bits larger than what JavaScript supports), then that's still not enough. As long as you want nanosecond-level granularity, and range beyond the current decade for your timestamps, you'll need more than 8 bytes to represent them in code.

I would argue dates with nanosecond granularity are of limited usefulness. In almost all use cases millisecond granularity is sufficient for dates, if you need nanosecond granularity chances are you also want a monotonic clock instead of real time that's subject to daylight savings, NTP correcting the clock etc.

I think it's mostly a usability tradeoff. If you can use the same data type for calendar appointments and high-precision performance logging, then you save your users the necessity of choosing between different types. Bonus points for being able to get away with a single nanosecond-based Duration type that has straightforward arithmetic with nanosecond-based timestamps.

And if you're deep enough to worry about the cost of those extra bits, you probably want to have your own date type anyway, tuned for your exact problem.

BigInt is in Stage 4 (https://github.com/tc39/proposal-bigint) which means that more than 2 implementations are shipping it unflagged. This is the last stage of any proposal in the TC39 process, which means it is de facto part of the standard.

BigInt is already in several modern browsers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Reply on news.ycombinator.com