[justthistime_]

As mentioned in the ticket, the original implementation is BSD.

Your last point is not the only thing that matters though. If the runtime already ships with packages X, there is no point in shipping your own implementation.

(Which is exactly what Scala/Scala.js does with math stuff: it reuses BigInteger from the runtime on the JVM, but ships its own implementation with Scala.js.)

[lomnakkus]

Right, but the JS and JVM runtimes have quite different behavior. And I'm willing to bet that implementing something as non-trivial as java.time again in Scala(.js) will end up causing quite a few bugs because they aren't identical.

That's why I'd rather have a single implementation for anything non-trivial and just retarget that to each backend using more low-level primitives. After all you're using a different language -- using a different date/time API shouldn't be much of a problem.

[justthistime_]

Yeah, inventing an API and implementation of a date/time/calendar library from scratch without an existing spec, implementation, tests or experience will surely be totally bug-free.

[lomnakkus]

I'm not sure why you're being sarcastic.

I'm not saying it'll be bug-free. My point is that it'll have exactly the same bugs on either platform. This may be preferable to having different bugs on different platforms.

[justthistime_]

Same bugs on different platforms are extremely hard to find.

Different bugs on different platforms are like an early Christmas present:

You don't even need to write tests which include your "expectations" of the result anymore.

Just call the code with randomized inputs for both platforms, and if there is a difference, you found a bug.

[lomnakkus]

That's a good point. As a (shim) library developer I think I might agree -- because it would perhaps be easier to find bugs in my library -- as an application developer I wouldn't because I would have to find different workarounds for different bugs.