The Device Clock Can Be Moved — Protecting Daily Features and Trial Logic from Time Tampering

A Trusted-Clock Provider Backed by a Server-Time Offset

You do not need a dedicated time API. Every response from a backend you already call carries the standard HTTP Date header — Cloudflare Workers return it out of the box. The trick is to store only the offset between server time and the device clock.

// trustedClock.ts — managing a server-time offset
import AsyncStorage from "@react-native-async-storage/async-storage";
 
const OFFSET_KEY = "trusted_clock_offset_ms";
let offsetMs: number | null = null;
 
// Call on app launch and on foreground return
export async function syncClock(endpoint: string): Promise<void> {
  const started = performance.now();
  const res = await fetch(endpoint, { method: "HEAD" });
  const rtt = performance.now() - started;
 
  const dateHeader = res.headers.get("date");
  if (!dateHeader) return;
 
  // Fold in half the round trip as a one-way latency estimate
  const serverNow = new Date(dateHeader).getTime() + rtt / 2;
  offsetMs = serverNow - Date.now();
  await AsyncStorage.setItem(OFFSET_KEY, String(offsetMs));
}
 
// A trustworthy "now". Falls back to the stored offset when offline
export async function trustedNow(): Promise<number> {
  if (offsetMs === null) {
    const stored = await AsyncStorage.getItem(OFFSET_KEY);
    offsetMs = stored !== null ? Number(stored) : 0;
  }
  return Date.now() + offsetMs;
}

The Date header only has second-level precision, which is far more than a daily boundary needs. In my measurements, a HEAD request to a Worker completed in roughly 60–120 ms round trip, and the corrected clock landed within ±1 second of server time. If a feature genuinely needs millisecond precision, this mechanism was never the right tool for it anyway.

The easy thing to miss is the offline case. Adding a stored offset does not help if the device clock itself has been moved — trustedNow() moves right along with it. So while offline, the offset gets demoted to a hint: reading cached content stays local, but granting anything of value requires an online check. That asymmetry — grant online, view locally — keeps the experience intact without leaving the door open.

Daily-Claim Logic Needs Rollback Detection as a Set

Even with server time deciding what "today" is, one hole remains: going offline, rolling the clock back, and replaying a cached judgment. That hole gets closed with a monotonicity check.

// dailyGate.ts — daily claim with rollback detection
import AsyncStorage from "@react-native-async-storage/async-storage";
import { trustedNow } from "./trustedClock";
 
const LAST_CLAIM_KEY = "daily_last_claim";
 
// Build the day key in the service's reference timezone
function dayKey(epochMs: number): string {
  return new Intl.DateTimeFormat("sv-SE", {
    timeZone: "Asia/Tokyo",
  }).format(new Date(epochMs)); // "2026-07-11"
}
 
export async function canClaimDaily(): Promise<boolean> {
  const now = await trustedNow();
  const raw = await AsyncStorage.getItem(LAST_CLAIM_KEY);
  if (!raw) return true;
 
  const last = JSON.parse(raw) as { at: number; day: string };
 
  // Monotonicity check: reject if time moved behind the last claim
  if (now < last.at - 60_000) return false;
 
  return dayKey(now) !== last.day;
}
 
export async function recordClaim(): Promise<void> {
  const now = await trustedNow();
  await AsyncStorage.setItem(
    LAST_CLAIM_KEY,
    JSON.stringify({ at: now, day: dayKey(now) })
  );
}

Two design decisions are worth spelling out.

First, the day boundary is pinned to the service's reference timezone rather than the user's. That prevents "today" from arriving twice on a long flight. A traveling user might see the daily drop arrive up to 14 hours late, but in my experience that is a far easier behavior to explain than a double grant.

Second, the rollback check carries a 60-second tolerance. Legitimate NTP corrections routinely step the clock back a few seconds, and blocking rewards over that only generates support email. The buffer lets normal corrections through while still catching deliberate rewinds.

For streak-style features, I also avoid the punitive version of this — resetting the streak to zero on any anomaly. A large share of clock weirdness happens with no malice at all. Making the user wait one extra day is enough, and it keeps the review section calm.

Never Use the Device Clock for Trials or Subscription Status

Even with all of the above in place, I do not build free trials on a local timer. The reasoning is blunt: the more value something protects, the stronger the incentive to attack it. Claiming tomorrow's wallpaper early and dodging a monthly subscription are different threat levels, and they deserve different mechanisms.

Fortunately, the billing stack already ships with server-signed time. The purchase and expiration dates inside a StoreKit 2 transaction are signed by Apple's servers; no amount of fiddling with the device clock rewrites them. The rule is to judge entitlement using signed values only and keep the device clock out of the loop entirely.

Free trials belong on App Store introductory offers, which move expiry management to Apple's side as well. If you use RevenueCat, entitlement checks are already server-side, and the only real question left is how long to trust the cached entitlement while offline — I've written about that trust window in designing the trust window for RevenueCat's offline entitlement cache, and about the broader state model in keeping StoreKit 2 subscription status stable with three-layer sync.

The inverse mistake exists too: pushing things that should follow the device's lived time — like local notification fire times — onto server time, which gets you notifications ringing at 3 a.m. after a timezone change. That trade-off is the mirror image of what I covered in re-syncing local notifications across timezone and DST changes.

Time Tampering Reproduces on Your Desk — a Test Procedure

The most reliable way to validate this design is to break it yourself before release. Here are the scenarios I run before shipping.

Android can be driven from adb, which makes semi-automated checks practical:

# Disable automatic time sync, then set an arbitrary time
adb shell settings put global auto_time 0
adb shell date 071220302026.00   # July 12, 20:30

The iOS Simulator cannot change the OS date, so this runs on a physical device with Settings > General > Date & Time set to manual. Skipping that one chore and shipping anyway — then finding out from the logs a week later — is exactly how this article started.

Closing: Pick Time Sources Once, Then Stop Deciding

Time handling is not something to re-litigate per feature. Decide the assignment once as a project convention — wall clock for display and notifications, monotonic clock for in-session intervals, server time for value and expirations — and every subsequent feature writes itself.

For a Rork-generated codebase, the practical starting point is a search for Date.now() call sites, replacing only the lines involved in granting value or judging expiration with trustedNow(). In my app that came to 12 call sites and about half a day of work.

If your app has any daily feature at all, run the test table above before your next release. Moving the clock forward a single day exposes the gaps in a design more honestly than any code review I've sat through.