| This a pretty magical solution. - Backward compatible. No API change. - Naive, idiomatic and wrong use of the API automatically becomes naive, idiomatic and correct: Existing code that was using wall-clock time will now be using monotonic time when it should, and only when it should [1] - No change to the memory footprint on 64-bit systems - No change to the range of representable dates [2] "No API change" means if for some reason it turns out to be a bad idea, they can still revert it and stay backward compatible (though of course, the documentation will mention how monotonic times are used to calculate better time differences and that would no longer be true after a revert). Very impressed with the extensive survey of existing code which didn't find a single case where the change would cause an issue. [1] Except when a user got out of their way to calculate a time difference in a non-idiomatic way. [2] The range is only restricted when monotonic time information is present, which cannot sensibly be the case outside the restricted range. |