doc: explicitly mention that Deadline might saturate

context/src/main/java/io/grpc/Deadline.java

@@ -55,6 +55,9 @@ public static Ticker getSystemTicker() {
    * Create a deadline that will expire at the specified offset based on the {@link #getSystemTicker
    * system ticker}.
    *
+   * <p>If the given offset is extraordinarily long, say 100 years, the actual deadline created
+   * might saturate.
+   *
    * @param duration A non-negative duration.
    * @param units The time unit for the duration.
    * @return A new deadline.
@@ -66,6 +69,9 @@ public static Deadline after(long duration, TimeUnit units) {
   /**
    * Create a deadline that will expire at the specified offset based on the given {@link Ticker}.
    *
+   * <p>If the given offset is extraordinarily long, say 100 years, the actual deadline created
+   * might saturate.
+   *
    * <p><strong>CAUTION</strong>: Only deadlines created with the same {@link Ticker} instance can
    * be compared by methods like {@link #minimum}, {@link #isBefore} and {@link #compareTo}.  Custom
    * Tickers should only be used in tests where you fake out the clock.  Always use the {@link
@@ -141,6 +147,9 @@ public Deadline minimum(Deadline other) {
 
   /**
    * Create a new deadline that is offset from {@code this}.
+   *
+   * <p>If the given offset is extraordinarily long, say 100 years, the actual deadline created
+   * might saturate.
    */
   // TODO(ejona): This method can cause deadlines to grow too far apart. For example:
   // Deadline.after(100 * 365, DAYS).offset(100 * 365, DAYS) would be less than