currentTimeMillis resolution still 10-50ms on Win?

Just wondering…
Why hasn’t currentTimeMillis() been updated so behind the scenes it uses nanoTime?

It would be nice if existing code didn’t have to be rewritten to improve the timer resolution.
(or is the contract of nanoTime() not compatible with currentTimeMillis())

I think that is exactly the case… currentTimeMillis must return the number of millis since the epoch - it is the basis of Date/timestamps and must match THAT clock.

I think nanoTime() is not synchronized with the main clock in the same way and is really only useful for measuring (short) intervals as opposed to establishing absolute time. Perhaps it even has significant drift with respect to wall clock time, so trying to sync the two times internally somehow probably isn’t worth it.