undefined | Better HN

0 pointsdmit6y ago0 comments

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.

0 comments

2 comments · 1 top-level

wongarsu6y ago· 1 in thread

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.

dmitOP6y 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.

j / k navigate · click thread line to collapse