Why Regional Game Timers Need an Evidence Model

A game-event countdown looks simple until one schedule must serve players in several regions. The display is only the last step. The real work is separating sourced facts, regional assumptions, time-zone conversion, and live game state.

Store the schedule as a reference, not a promise

For a repeating event, I prefer a small record that names its scope:

type RiftReference = {
  service: "taiwan" | "korea" | "custom";
  utcOffsetMinutes: number;
  firstStartHour: number;
  intervalHours: number;
  entryWindowMinutes?: number;
  evidence: "official-guide" | "community" | "user-observed";
  sourceUrl?: string;
  checkedAt: string;
};

That evidence field matters. An official Taiwan guide can support a three-hour reference cycle and a described entry window, while a Korea clock anchor may still be community-derived. A custom or future Global clock should begin with the player's own observation. Putting these cases into one unlabeled array would make the interface look more certain than the data.

Convert instants, not labels

The server schedule should be converted into absolute instants before it is formatted for the browser. A label such as 02:00 is incomplete by itself: it needs a service offset and a server date. Once that instant exists, the browser can display the user's local time and weekday safely.

The next occurrence can be derived by advancing from the reference start in fixed intervals until the candidate is later than the current instant. Generate a full reference day from the same rule so the countdown and schedule table cannot drift apart.

const starts = Array.from({ length: 8 }, (_, index) =>
  addHours(referenceStart, index * 3)
);

The same calculation also exposes date-boundary bugs. A Monday server start may display on Sunday or Tuesday for a player elsewhere, so the local weekday belongs beside the local time.

Keep schedule state separate from live state

A recurring timetable answers, “When is the next expected opening?” It cannot prove that a portal is currently visible, has capacity, or survived a maintenance change. The UI should say that directly and let in-game information win when the two disagree.

For an ordinary portal window, the timer can switch from “time until reference start” to “estimated entry window remaining” after the start. That is still a guide-based estimate. It should never be labeled as a live server feed.

Make calibration part of the product

Regional uncertainty is easier to handle when users can set a UTC offset and cycle anchor. Store those preferences locally, show the resulting schedule in both server and local time, and keep the reminder optional. A browser notification should also disclose that the tab must remain open and that sleep or background throttling may delay it.

I used this model in AION 2 Rift Atlas, which keeps its Taiwan, Korea, and custom references visibly distinct and links schedule claims to their evidence. The useful lesson is broader than one game: if a timer cannot explain where its clock came from, it should not present the countdown as authoritative.