ref(time): Deprecate the legacy date and clock providers (JAVA-571)

[runningcode]

PR Stack (Clock semantics hardening)

• feat(time): Add uptime and elapsed-real-time clock abstractions (JAVA-571) #6028
• feat(time): Add Timestamp, Timing and EpochClock (JAVA-572) #6045
• fix(android): Treat an unpopulated connection cache as stale (JAVA-717) #6029
• ref(transport): Measure rate-limit backoff on a monotonic clock (JAVA-574) #6030
• ref(checkin): Measure check-in durations with Stopwatch (JAVA-576) #6032
• ref(android): Measure ANR thresholds on the uptime clock (JAVA-579) #6041
• this PR

---

📜 Description

Marks the legacy date and clock surface as deprecated, now that the internal consumers that could
move have moved (#6029, #6030, #6032, #6041). Nothing is migrated here and nothing is removed — the
point is to start the warning cycle before the next major, so users and the 9.x.x branch get a
full release of notice.

Deprecated	Replacement
ICurrentDateProvider.getCurrentTimeMillis()	UptimeClock / ElapsedRealtimeClock, whichever the site actually meant
CurrentDateProvider.getInstance()	SentryDateProvider for a timestamp, ElapsedRealtimeClock for an interval
AndroidCurrentDateProvider.getInstance()	UptimeClock (this one was SystemClock.uptimeMillis() all along)
DateUtils.getCurrentDateTime()	options.getDateProvider().now()
AndroidDateUtils.getCurrentSentryDateTime()	options.getDateProvider()

The DateUtils class is deliberately not deprecated: only getCurrentDateTime() reads a clock,
while its other fourteen statics are pure conversion and formatting helpers used all over the SDK.

Two deviations from the plan, both forced

1. The annotations sit on members, not on the types. The plan called for deprecating
ICurrentDateProvider, CurrentDateProvider and AndroidCurrentDateProvider as types. That cannot
compile here: the Android modules build at Java 8, where javac still emits a deprecation warning for
an import of a deprecated type (JEP 211 elides those only from source 9 on), -Xlint:all -Werror
turns it into an error, and an import declaration cannot carry a @SuppressWarnings — a class-level
suppression does not cover it either. I verified both halves of that empirically. Thirteen Java files
in sentry-android-core import these types; the alternative was writing
io.sentry.transport.ICurrentDateProvider inline at ~40 use sites until the next major.

Deprecating getCurrentTimeMillis() and getInstance() warns any caller just as loudly, and every
warning it produces lands somewhere a suppression can go. The type-level javadoc still names the
replacement, so IDEs and Javadoc readers see it.

2. Kotlin call sites are left warning, not suppressed. -Werror applies to JavaCompile only,
so the 17 warnings in sentry-android-replay and sentry-okhttp do not break anything. They are the
live migration list for JAVA-575; suppressing them would trade a checklist for a comment. That module
already carries other deprecation warnings, so this is not a new kind of noise. Say the word if you'd
rather have them suppressed.

💡 Motivation and Context

ICurrentDateProvider is the defect JAVA-571 was filed about. One interface carried two
incompatible clocks — CurrentDateProvider is System.currentTimeMillis(), AndroidCurrentDateProvider
is SystemClock.uptimeMillis() — and nothing in the name or the type said which. A field declared
ICurrentDateProvider accepts either, and the two disagree by however long the device has been
suspended.

Each of the 21 Java suppressions carries a // TODO [MAJOR] naming the replacement that site should
take, because a suppressed warning stops being a checklist entry. Nearly all of them are frozen until
the next major because they produce serialized timestamps — SentryEvent, Breadcrumb, Session,
SentryReplayEvent, ProfilingTraceData, both profilers, the activity-lifecycle span helpers. Only
ClientReportRecorder and EnvelopeCache are internal. That is expected: this PR marks the surface,
it does not migrate it.

Four sites must stay on the wall clock and say so: AnrV2Integration, TombstoneIntegration and
ApplicationExitInfoHistoryDispatcher compare against epoch ApplicationExitInfo timestamps, and
LifecycleWatcher against Session.getStarted().

• resolves: JAVA-571

💚 How did you test it?

No behaviour changes, so no new tests — this is annotations plus suppressions.

./gradlew :sentry:test :sentry:apiCheck :sentry-android-core:testReleaseUnitTest :sentry-android-core:apiCheck :sentry-android-replay:testReleaseUnitTest :sentry-okhttp:test :sentry-apache-http-client-5:test — green.

./gradlew spotlessApply apiDump produces no .api diff: BCV does not record annotations.

📝 Checklist

• I added GH Issue ID & Linear ID
• I added tests to verify the changes.
• No new PII added or SDK only sends newly added PII if sendDefaultPII is enabled.
• I updated the docs if needed.
• I updated the wizard if needed.
• Review from the native team if needed.
• No breaking change or entry added to the changelog.
• No breaking change for hybrid SDKs or communicated to hybrid SDKs.
• Public API changes reviewed by another Mobile SDK team member or implemented according to the develop docs spec.

🔮 Next steps

The removals, and the serialized-value migrations behind every // TODO [MAJOR] here, belong to the
9.x.x branch: JAVA-572 (span durations), JAVA-575 (replay timings), JAVA-577 (session durations),
JAVA-578 (profiler re-anchoring), JAVA-642 (app-start spans).

⚠️ Merge this PR using a merge commit (not squash), so the rest of the stack keeps a clean history.

[linear-code]

JAVA-571

[sentry]

📲 Install Builds

Android

🔗 App Name	App ID	Version	Configuration
SDK Size	io.sentry.tests.size	8.54.0 (1)	release

⚙️ sentry-android Build Distribution Settings