Skip to content

ref(time): Read the epoch time from EpochClock (JAVA-836) - #6588

Draft
runningcode wants to merge 1 commit into
mainfrom
no/java-836-epoch-clock-callers
Draft

runningcode wants to merge 1 commit into
mainfrom
no/java-836-epoch-clock-callers

Conversation

@runningcode

Copy link
Copy Markdown
Contributor

📜 Description

Moves the call sites that use CurrentDateProvider only to read the current epoch time onto options.getEpochClock():

  • ApplicationExitInfoHistoryDispatcher: the 90-day cutoff for ApplicationExitInfo timestamps. It now reads the clock from the options it already holds, so AnrV2Integration, TombstoneIntegration and MemoryLimiterIntegration no longer take a date provider. Their only other constructors were package-private and passed CurrentDateProvider.getInstance() anyway.
  • SentryOkHttpInterceptor and SentryOkHttpEvent: HTTP_START_TIMESTAMP and HTTP_END_TIMESTAMP on the breadcrumb that Session Replay reads.

Each one compares against or sends an epoch instant, so each stays on the wall clock. EpochClock is the wall clock: System.currentTimeMillis() on Android, and Instant on Java 9+, which gives the same millisecond. No values change.

Adds Timestamp.epochMillis() for the call sites that need milliseconds.

💡 Motivation and Context

Fewer callers left for v9 to change when it removes ICurrentDateProvider (JAVA-827), and fewer @SuppressWarnings("deprecation") for the deprecation PR (JAVA-839).

Left alone on purpose:

💚 How did you test it?

  • New TimestampTest case for epochMillis() truncation.
  • AnrV2IntegrationTest, TombstoneIntegrationTest, MemoryLimiterIntegrationTest, ApplicationExitInfoCrossIntegrationTest (78 tests) and all of sentry-okhttp (150 tests) pass. The tests already used the real clock, so they now go through the public constructors.

📝 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

JAVA-839 deprecates CurrentDateProvider.getInstance() and the rest of the legacy clock surface.

#skip-changelog

🤖 Generated with Claude Code

The ApplicationExitInfo cutoff and okhttp's replay breadcrumb timestamps
only need the current epoch time, which options.getEpochClock() gives.
Moving them off CurrentDateProvider changes no values, and leaves fewer
callers for v9 to touch when it removes ICurrentDateProvider.

The three exit-info integrations no longer take a date provider: the
dispatcher reads the clock from the options it already has.

Timestamp.epochMillis() converts for the call sites that need millis.

Fixes JAVA-836

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@linear-code

linear-code Bot commented Nov 12, 2026

Copy link
Copy Markdown

JAVA-836

@sentry

sentry Bot commented Nov 12, 2026

Copy link
Copy Markdown

📲 Install Builds

Android

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

⚙️ sentry-android Build Distribution Settings

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Read epoch instants from EpochClock instead of CurrentDateProvider

1 participant