[Pitch] UTCClock

[xwu (Xiaodi Wu)]

@Philippe_Hausler

It was considered to add a new Instant type instead of depending on Date however this was rejected since it would mean re-implementing a vast swath of the supporting APIs for Calendar and such. The advantage of this is minimal and does not counteract the additional API complexity.

Given the recent conversation about issues with the floating-point representation that underpins Date and uncertainty whether this is fixable, is this pitch doubling down on the known problem?

Can there be alternatives considered such that any new APIs are generic over, say, some UTCClockInstantProtocol so that Date could be drop-in replaced?

Otherwise, by introducing additional API here that takes only a concrete Date, it is a self-fulfilling rationale that it results in an even vaster swath of APIs that would need replacing if Date needs to be replaced.