Every java.time.Clock also contains a time zone, and it can be freely used to produce zone-dependent values; as in LocalDate.now(clock). However, we've found that most users really just want zoneless Instants (the zone component usually comes from the user session, not the server).

Inside of Google we have a TimeSource interface, that looks like this:

public interface TimeSource {

  static TimeSource system() { ... }

  Instant now();

  default LocalDateTime now(ZoneId zoneId) { ... }

  default LocalDate today(ZoneId zoneId) { ... }

  default Clock asClock(ZoneId zoneId) { ... }
}

We strongly recommend its use over java.time.Clock, and its usage outnumbers Clock by 8x at this point.

We'd like to contribute this to threeten-extra, but a few obstacles:

1. we now have 30k+ references to our TimeSource, which makes migration very difficult (even for something as simple as a package/class rename).

2. threeten-extra already has a TimeSource interface in org.threeten.extra.scale. That interface is nearly what we want, minus the UtcInstant and TaiInstant-returning methods. Do you see any path forward for harmonizing these interfaces? What are the stability guarantees for threeten-extra?

Thanks,
-Kurt (on behalf of Google's "GoodTime" team)