> floats will cause issues with rounding or difference wrt roundtrips, not to > mention stringification
I don't think the same issues apply to timestamps. They're not user-visible in raw form, and you're not usually working with adjacent timestamps that are nanoseconds apart, so it doesn't matter if they're off by some tiny epsilon. I like the fact that you never have to worry about overflows. And treeform's point about lack of int64 in JS is important — a lot of JS parsers, in various languages, just parse _any_ number to float64. C++'s std::chrono module does support arbitrary backing types for times (it's a template parameter) but IMHO that contributes to making the library super awkward to use; you have to invoke a manual conversion function to cast times to different units.
