Why nanoseconds break most converters
JavaScript numbers are 64-bit floats with 53 bits of integer precision. Every integer above 9,007,199,254,740,991 is rounded, so Number("1700000000123456789") becomes 1700000000123456800 and the last digits are gone. JSON parsers, spreadsheets and many online converters take that path without warning.
This page keeps the input as text and converts it with BigInt. The precision panel compares the exact value with the Number reading and with what a JavaScript Date can hold (whole milliseconds). Then you can see exactly how many nanoseconds each step would lose.
Examples to try
Signed 64-bit limits
Go time.UnixNano(), pandas Timestamp and Arrow timestamp[ns] store nanoseconds in a signed 64-bit integer. That only covers 1677-09-21 to 2262-04-11. Values outside that window convert fine here, and the converter adds a note that those runtimes cannot represent them.
Questions
- Can JavaScript Date store nanoseconds?
- No. Date stores whole milliseconds, so the last six digits of a nanosecond timestamp are dropped. Use BigInt, or Temporal.Instant in runtimes that support it.
- How do I convert nanoseconds to seconds?
- Divide by 1,000,000,000. The converter shows the exact decimal (1700000000.123456789) and the floored integer seconds.
- What is the 2262 problem?
- Signed 64-bit nanoseconds overflow at 2262-04-11T23:47:16.854775807Z. Systems that use int64 nanoseconds (Go, pandas, Arrow) cannot represent later instants.