Super Bowl Sunday date calculator
The Super Bowl Sunday date calculator returns the traditional date associated with the game for a year you provide: the second Sunday of February.
Run — free
It uses deterministic Gregorian calendar arithmetic and expresses the answer as UTC calendar fields, so the result does not depend on a device timezone, daylight-saving transition, locale, network source, or current clock. The response includes a sortable ISO date and the underlying rule fields, making it suitable for schedules, editorial calendars, event planning, and reproducible software tests.
What this traditional date means
This calculator answers a deliberately narrow calendar question: which date is the second Sunday of February in the requested Gregorian year? That rule is commonly used as the traditional modern date for Super Bowl Sunday. Enter one year from 1 through 9999 and the result supplies the ISO-formatted date, numeric month and day, weekday, occurrence number, named rule, calendar, and UTC designation. The calculation does not consult a sports schedule, identify participating teams, predict kickoff time, or claim that an officially announced game can never move. Those distinctions matter when an editorial calendar needs a stable convention before a league schedule is available. They also keep the output clear for historical or hypothetical years where an event may not have existed. Treat the result as a rule-based calendar date rather than live event data. If your workflow needs an officially scheduled venue, broadcast time, or matchup, combine this deterministic value with an authoritative schedule source after announcements are published. The API price is $0.002 per request, while the same pure computation can run in the browser without sending the year elsewhere.
How the second Sunday is calculated
The algorithm first determines the weekday of February 1 using integer arithmetic for the proleptic Gregorian calendar. Sunday is represented consistently within that calculation, allowing the function to measure the bounded offset from the first day of the month to its first Sunday. It then adds exactly seven days to reach the second Sunday. Consequently, the returned day of the month is always between February 8 and February 14, an invariant that makes the result easy to audit. The year is required to be a finite integer between 1 and 9999; strings, fractions, missing values, and out-of-range numbers are rejected rather than guessed, rounded, or silently converted. The ISO year is padded to four digits, so even early supported years produce a stable sortable shape. No JavaScript Date object is used. That design avoids implementation-dependent parsing, local timezone offsets, daylight-saving behavior, and host clock settings. There is also no network request, random input, mutable cache, or dependence on the present day. Supplying the same valid year therefore always produces the same JSON result in the API and browser execution paths.
Using the result in calendars and automation
Use the date field when you need a compact YYYY-MM-DD value for a database key, reminder seed, content deadline, or test fixture. The separate year, month, and day fields are convenient for systems that build calendar objects themselves, while weekday and occurrence make the reason for the answer visible without reverse engineering it. The rule value is especially useful in audit logs: it records that the result came from the second-Sunday convention, not from a scraped fixture list. For event planning, teams can work backward from this date to set publishing deadlines, staffing reviews, menu preparation, promotional windows, or inventory checks. For software quality assurance, select years where February begins on different weekdays and confirm that downstream reminders still land on Sunday between the eighth and fourteenth. Remember that UTC here describes the deterministic calendar frame used for the returned fields; it is not a kickoff timestamp and should not be converted as though midnight UTC were the event start. When an official schedule is the legal or operational authority, retain that schedule as the final source and use this result for planning, placeholders, or consistency checks.
What you can do with it
Prepare an editorial calendar
Place a stable Super Bowl Sunday placeholder into a yearly publishing plan before detailed event information is available.
Schedule hospitality preparation
Anchor staffing, purchasing, menu, and promotion milestones to the traditional second Sunday of February.
Build reproducible date tests
Generate deterministic fixtures for software that creates annual reminders or validates recurring February dates.
FAQ
What rule does the calculator use?
It returns the second Sunday of February in the requested proleptic Gregorian year.
Does this use the official NFL schedule?
No. It computes the stated traditional calendar rule and does not fetch live schedules, venues, teams, or kickoff times.
Why does the output mention UTC?
UTC identifies the stable calendar frame for the returned fields. The result is a date, not a midnight kickoff timestamp.
Which years are accepted?
The input must be a numeric integer from 1 through 9999. Numeric strings and fractional values are rejected.
How much does an API request cost?
Each API request costs $0.002. The pure calculation is also available through the free browser experience.
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/date/super-bowl-sunday \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"year":2026}'const res = await fetch("https://api.kit.forhosting.com/date/super-bowl-sunday", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"year": 2026
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/super-bowl-sunday",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"year": 2026
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/super-bowl-sunday", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"year":2026}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"year":2026}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/super-bowl-sunday", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"year": 2026
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.super_bowl_sunday",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |