When a User Rewinds the Clock, Today's Card Shouldn't Break — Day Boundaries and Streak Integrity in a Daily-Content App

Don't lose the midnight rollover

If the app stays open across a date change, the screen keeps showing "yesterday's card" forever. A common fix is setTimeout(handleMidnight, msUntilMidnight), but it loses events: iOS suspends background timers, and if the device sleeps through midnight it never fires.

The reliable mindset is "recompute on resume," not "wait on a timer." On AppState returning to active, and on a light foreground interval, just check whether todayKey() still equals the held key.

// hooks/useDailyContent.ts
import { useEffect, useRef, useState } from "react";
import { AppState } from "react-native";
import { todayKey } from "../lib/dayKey";
 
export function useDailyContent() {
  const [key, setKey] = useState(todayKey());
  const keyRef = useRef(key);
  keyRef.current = key;
 
  useEffect(() => {
    const check = () => {
      const now = todayKey();
      if (now !== keyRef.current) setKey(now); // date advanced -> swap
    };
 
    const sub = AppState.addEventListener("change", (s) => {
      if (s === "active") check(); // re-check on every resume
    });
    // For people who leave the screen open, a light foreground check.
    const id = setInterval(check, 60_000);
 
    return () => {
      sub.remove();
      clearInterval(id);
    };
  }, []);
 
  return key; // pull content from this dayKey
}

The timer is decorative; the truth lives in re-evaluating todayKey(). The one-minute setInterval is only for someone who leaves the screen open past midnight, and even if it drifts, the resume check always catches up.

Keep a rewound clock out of the streak

This is the crux. If you count streaks by trusting Date, a user who jumps a day forward, collects a reward, and jumps back gets credited twice. And a legitimate user whose clock rewinds after travel can lose a record unfairly.

The key is to run two clocks. Use the wall clock (Date) for the date decision, and a monotonic signal to detect rewinds. By storing the last observed wall time, you can spot the contradiction "the wall clock moved forward but cannot be trusted to have done so."

// lib/streak.ts
import AsyncStorage from "@react-native-async-storage/async-storage";
import { todayKey } from "./dayKey";
 
type StreakState = {
  lastDayKey: string;   // last day completed
  count: number;        // consecutive days
  lastSeenWall: number; // last observed wall time (ms)
};
 
const KEY = "streak.v1";
 
function diffInDays(a: string, b: string): number {
  // Day difference between dayKeys. Anchor at UTC noon to erase DST edges.
  const da = new Date(`${a}T12:00:00Z`).getTime();
  const db = new Date(`${b}T12:00:00Z`).getTime();
  return Math.round((db - da) / 86_400_000);
}
 
export async function recordToday(): Promise<StreakState> {
  const raw = await AsyncStorage.getItem(KEY);
  const now = Date.now();
  const today = todayKey();
 
  if (!raw) {
    const fresh = { lastDayKey: today, count: 1, lastSeenWall: now };
    await AsyncStorage.setItem(KEY, JSON.stringify(fresh));
    return fresh;
  }
 
  const s: StreakState = JSON.parse(raw);
 
  // Wall clock jumped into the past -> suspected tampering. Hold, do not add.
  if (now < s.lastSeenWall - 60_000) {
    s.lastSeenWall = now;
    await AsyncStorage.setItem(KEY, JSON.stringify(s));
    return s;
  }
 
  const gap = diffInDays(s.lastDayKey, today);
 
  if (gap <= 0) {
    // Opened multiple times the same day. No double count.
    s.lastSeenWall = now;
  } else if (gap === 1) {
    s.count += 1;          // legitimate continuation from yesterday
    s.lastDayKey = today;
    s.lastSeenWall = now;
  } else {
    // Two or more days skipped. To allow one grace day, treat gap === 2 as continued.
    s.count = 1;
    s.lastDayKey = today;
    s.lastSeenWall = now;
  }
 
  await AsyncStorage.setItem(KEY, JSON.stringify(s));
  return s;
}

Three things matter. First, the increment decision uses only the dayKey difference, never the fine-grained Date delta. Second, any number of opens within the same dayKey is rejected by gap <= 0, so double counting cannot happen structurally. Third, when the wall clock leaps far backward, that pass holds the record and skips the increment. That blocks "jump forward then back" inflation while never erasing a legitimate user's record.

Don't let travel mean "skip a day" or "arrive twice"

As long as dayKey is generated in a fixed timezone, a user flying from Japan to Hawaii keeps Asia/Tokyo as the basis, so the boundary never wobbles. On a local-time basis, flying east shortens a day and breaks streaks easily, while flying west stretches a day so the same day arrives twice. For publisher-driven content, a fixed timezone is the simplest fix that wipes out traveler accidents.

For apps that must use local time (a habit tracker where the person's life is the subject), anchoring diffInDays at UTC noon is what saves you. Wrapping the keys in T12:00:00Z prevents a one-hour edge from nudging the day count by ±1 across DST. Subtract dates naively with raw getTime() deltas and you will trip here every time.

Verify by moving the clock by hand

This kind of logic only reveals its holes when you manipulate time on a real device. Run at least this before release.

diffInDays and recordToday are kept close to side-effect-free pure functions, so locking down the boundaries (gap of 0/1/2, wall-clock rewind) with unit tests is reassuring. Date bugs are hard to reproduce and easy to miss in review, so drawing a line with tests is especially worth it here.

The whole feel of daily content rides on this one quiet detail. Start by standing up a single dayKey function and routing every scattered new Date() comparison through it. Even just removing the display drift should noticeably cut the confused messages that reach your support inbox.