Length of daylight calculator by date and latitude
This length of daylight calculator estimates how many hours the Sun remains above the conventional sunrise horizon for a specified calendar date and latitude.
Run — free
It uses only the supplied values, performs the calculation with a standard solar declination and hour-angle formula, and never reads a clock or calls an outside service. The result is useful for planning, comparison, education, and data processing when a consistent approximation matters more than a location-specific astronomical almanac.
Enter an exact date and geographic latitude
Provide the date in strict ISO form, using four digits for the year followed by a two-digit month and day, such as 2026-06-21. Then provide latitude in decimal degrees from -90 to 90. Positive values describe places north of the equator, while negative values describe places south of it. Longitude and time zone are intentionally unnecessary because the requested quantity is the duration between the theoretical sunrise and sunset events, not their local clock times. The calculator validates the real Gregorian calendar, including the century rules for leap years, so impossible entries such as February 30 are rejected instead of silently adjusted. It also derives the ordinal day entirely through arithmetic. That makes an identical input produce an identical answer regardless of the computer, locale, current date, or UTC offset where it runs. Use a representative latitude for a city or site; moving farther north or south can materially change the estimate, especially near a solstice or inside a polar region. Decimal precision is accepted, but excessive coordinate precision does not make this approximate model an observatory-grade prediction.
Understand the solar approximation
The calculation first maps the calendar date to its day of year and estimates solar declination, the seasonal angle of the Sun north or south of Earth’s equator. It then applies the standard sunrise hour-angle relationship for the supplied latitude. Sunrise and sunset use a solar altitude of minus 0.833 degrees, a conventional correction that approximately accounts for atmospheric refraction and the visible radius of the Sun near the horizon. The resulting hour angle is converted into a duration over a 24-hour rotation and rounded to four decimal places for stable output. When the geometry says the Sun never drops below that conventional horizon, the response reports 24 hours and marks the condition as polar day. When it never rises above it, the response reports zero hours and marks polar night. All other cases are marked normal. This is a mathematical estimate: it does not model elevation, mountains, buildings, unusual atmospheric pressure, temperature, local terrain, or the small year-to-year changes represented by a full astronomical ephemeris.
Use the result with the right expectations
Treat daylight_hours as a consistent planning value rather than a promise of visible sunshine. Cloud cover does not alter astronomical day length, but terrain can hide the Sun after the formula’s idealized sunset or delay its appearance after idealized sunrise. At high latitudes, a small change in date or position may create a large change in duration, so calculate every date needed instead of extrapolating a whole season from one sample. The day_of_year field makes the calendar position explicit, and condition distinguishes ordinary sunrise-and-sunset geometry from polar edge cases. Because no longitude is requested, the capability does not return sunrise or sunset clock times; those depend on longitude, time zone, and civil-time rules. The deterministic approach is especially helpful in automated pipelines, unit tests, classroom demonstrations, agricultural comparisons, and travel planning where repeatability is valuable. Save both the original date and latitude with the result so another person can reproduce it. For navigation, safety-critical fieldwork, religious observance, or precise scientific measurement, consult an authoritative local ephemeris that incorporates coordinates, elevation, and current atmospheric assumptions.
What you can do with it
Compare seasonal daylight
Calculate the same latitude on several dates to show how daylight changes from winter through summer.
Plan outdoor schedules
Estimate the daylight window available for travel, photography, construction, gardening, or field activities.
Enrich a calendar dataset
Add reproducible approximate daylight duration and polar-condition labels to dated geographic records.
FAQ
What does one calculation cost?
One API request costs $0.002. The browser calculator can run the same deterministic logic locally.
Why does the calculator not ask for longitude?
Longitude changes the clock time of sunrise and sunset, but not their approximate separation for a date and latitude.
Is this an exact astronomical ephemeris?
No. It is a standard approximation and does not include terrain, elevation, weather, or a full solar ephemeris.
How are leap years handled?
The input follows Gregorian rules: years divisible by four are leap years except non-divisible-by-400 century years.
What do polar day and polar night mean?
They indicate that the formula finds no conventional sunset or no conventional sunrise, producing 24 or zero daylight hours.
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/day-length-approx \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"2026-06-21","lat":51.5074}'const res = await fetch("https://api.kit.forhosting.com/date/day-length-approx", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"date": "2026-06-21",
"lat": 51.5074
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/day-length-approx",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"date": "2026-06-21",
"lat": 51.5074
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/day-length-approx", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"date":"2026-06-21","lat":51.5074}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"date":"2026-06-21","lat":51.5074}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/day-length-approx", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"date": "2026-06-21",
"lat": 51.5074
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.day_length_approx",
"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. |