Data Methodology

1. Data sources

We limit the primary sources of schedule data to publishers' official channels. Secondary sources such as wikis and news articles are used only as fact-checking references — we don't copy their content into our data.

• Official announcements, developer blogs, and patch notes
• Official publisher forum notices
• Official publisher RSS feeds

2. Verification process

From collection to publication we follow the steps below. Automated collection produces candidates first; a person then cross-checks them against official announcements to confirm or correct them.

1. Automated collection: crawl official channels to gather season and league schedule candidates.
2. Official cross-check: compare each candidate directly against the publisher's official announcement.
3. Human review and correction: the editorial team confirms or edits before publishing, and corrects any error found later.

3. How we measure cadence

Almost every derived figure on this site comes from "cadence". How you define it changes every number downstream, so here is the rule set up front.

• Cadence is the gap from one season's start to the next season's start. We do not use season length (end minus start), because a large share of end dates are estimates — measuring with them would present estimates as fact.
• When an expansion or major update occupies a regular slot, it still counts as a cadence boundary. Dropping those rows invents gaps in a rhythm that never actually broke. Diablo Immortal is the clearest case: two of its 28-day slots were filled by expansions.
• Conversely, a game with no season cycle at all is excluded outright — imposing a cadence on an expansion-only title (Grim Dawn) or one that has not adopted seasons (No Rest for the Wicked) would manufacture a pattern that does not exist.
• Within one game, rows sharing an identical start time are collapsed into one. Two seasons of the same game cannot begin at the same instant, so such rows are not two boundaries — they are one season loaded twice. Left alone they create zero-day gaps that corrupt medians and forecasts alike.
• We report the median, not the mean. One or two long droughts (a studio going quiet for six months) drag an average far more than they shift a median.

4. Two kinds of estimate — end dates and next start dates

This site produces two kinds of estimated value, and they differ in character. Both are visually separated from confirmed information.

1) Estimated end dates

Season start dates are generally backed by an official announcement, but official end dates usually are not published. So we leave the end date blank for a season that is still running — writing a closing date onto an open season makes it read as confirmed. For seasons that have ended, the end date is in most cases derived from the next season's start, and we publish that proportion (166 of the 218 rows that carry an end date, 76%) on the analytics page. The derivation may combine rule-based calculation with supporting language-model inference.

Real cases where estimation concentrates on end dates:

• Path of Exile: of the 41 tracked leagues, 40 carry an end date and 39 of those are estimates (the remaining one has no confirmed end date).
• Diablo III: 38 of the 39 tracked seasons have an estimated end date.
• Start dates are mostly based on official announcements; estimation applies mainly to end dates.

2) Forecast next start date

So that we can still answer "roughly when is the next one" during the stretches when a publisher has announced nothing, we estimate the next start from that game's distribution of past intervals. The rules:

• Point estimate = the last confirmed season start plus that game's median interval.
• Window = the 25th and 75th percentile intervals added to the same anchor. A point estimate alone hides uncertainty, so we always show the window with it.
• Games with fewer than four intervals get no date at all. That bar is stricter than the one for showing a median (three), because "the median is N days" summarises observations while "the next one is this date" is a much stronger claim.
• Confidence is graded on the width of the window relative to the median interval, not on absolute days. Ten days of spread means something entirely different on a 28-day cycle than on a 120-day one.
• "Past due" means one of two things — the publisher is running late, or a season has already begun and we have not yet confirmed it against a primary source. We do not claim to know which.

5. Prediction log — accruing from now on

Every forecast we publish is recorded with the date we made it and later checked against the actual start. Crucially, only seasons that begin after the recording date count toward a result. Pulling in an earlier season would be recording what we already knew rather than predicting it. For the same reason we never reconstruct past predictions — inventing a forecast we have no record of making is authorship, not history. Accuracy therefore only becomes meaningful with time.

6. Scope of the announcement lead-time table

The table answering "how many days ahead does a publisher tell you the date" includes only entries whose official announcement page shows its own posting date. We do not treat secondary reporting of "it was announced on the Nth" as evidence. This matters in practice: several outlets dated one league's announcement to its reveal stream, while the publisher's own post stating the release date had gone up ten days earlier. The announcement date here means the day the start date became public, not the day the league was first teased. The table therefore covers a stated scope rather than every season, and that scope is printed beneath it.

7. Correction policy

When an error is found, we correct it against the publisher's official announcement. Facts confirmed after the fact — such as a scheduled start date that actually slipped — are retroactively updated to confirmed values. Error reports are always welcome.

8. We don't hide missing data

For some games we could not confirm past schedules from primary sources, so we left those gaps empty rather than filling them from secondary sources. Known gaps are as follows.

• Undecember: some early entries could not be confirmed, so only 7 seasons are included.
• Path of Exile: some very early league dates (around 2013) are approximate.
• No Rest for the Wicked: no recurring season has been introduced yet, so we carry only its expansion and update entries.
• Grim Dawn: runs on an expansion model rather than seasons.

9. Time zone used for display

Season start and end times are stored in the database as UTC and converted only when they are rendered, on a basis fixed per language. Korean pages use KST (Korea Standard Time) and English pages use UTC, with the applicable badge shown next to each date. A visitor's browser time zone is never used for display, because a page that shows different dates depending on where it is opened cannot be cited or compared screen to screen.

The month axis and the displayed window on the calendar and analytics pages are an exception: they stay fixed to UTC regardless of language. If the boundaries of an aggregation window followed the per-language time zone, the window would shift by nine hours and figures such as the maximum number of concurrent seasons would differ between Korean and English. Keeping the axis on a single UTC basis is what makes the aggregate results identical in both languages, so the month axis is treated as a fixed analytical axis and labelled UTC on screen.