3 ms·

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 Big

by mikece 7y ago

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.

manigandham 7y ago
BigInt is already in several modern browsers: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/BigInt https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
dmit 7y ago
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.
- wongarsu 7y ago
  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.
  - dmit 7y ago
    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.
frutiger 7y ago
BigInt is in Stage 4 (https://github.com/tc39/proposal-bigint 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.

by mikece 7y ago

manigandham 7y ago

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

dmit 7y ago

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.

wongarsu 7y ago
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.
- dmit 7y ago
  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.

frutiger 7y ago

BigInt is in Stage 4 (https://github.com/tc39/proposal-bigint 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.