First and last day of year
For June 15, 2024, the year runs from 2024-01-01 to 2024-12-31 and has 366 days because it is a leap year. Use the two dates as ready-made limits for annual reports, filters, archive folders or retention labels. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Date
- 2024-06-15
- Year
- 2,024
- First day
- 2024-01-01
- Last day
- 2024-12-31
- Days in year
- 366
This first and last day of year calculator takes one explicit ISO calendar date and returns the two inclusive boundaries of the same civil year. It is useful when a report, filter, archive, or validation rule needs January 1 and December 31 without consulting the current clock. The input is checked as a real Gregorian date, including the century rules for leap years, before any result is produced. The response also identifies the year, whether it is a leap year, and its total number of days.
How the year boundaries are derived
Provide a date with exactly four year digits, two month digits, and two day digits separated by hyphens. The calculator first separates those components and validates them under the proleptic Gregorian calendar. A month must be between 01 and 12, while the permitted day depends on the month and year.
February receives 29 days when the year is divisible by four, except century years must also be divisible by four hundred; therefore 2000 is a leap year, 1900 is not, and 2024 is. Once the explicit date is known to exist, only its year component is needed for the boundaries. The first inclusive day is that four-digit year followed by 01-01, and the last inclusive day is the same year followed by 12-31.
Neither boundary changes in a leap year: the extra day occurs inside February, while January 1 and December 31 remain fixed. The calculation is constant-time and makes no external calls.
Which dates are accepted and what you get back
Send an object containing the required date field, for example 2024-06-15. The accepted syntax is deliberately strict: abbreviated months such as 2024-6-15, slash-separated dates, timestamps, surrounding spaces, and localized date phrases are rejected. Strictness prevents an apparently convenient parser from interpreting the same text differently on two machines.
Syntax alone is not enough, so the capability also rejects month zero, month thirteen, April 31, February 30, and February 29 in a common year. The input date is always explicit and required, so omitting it never falls back to today. This property makes saved requests, tests, and historical data jobs reproducible years later.
Using calendar-year bounds safely
Calendar-year boundaries are especially useful for annual database queries, report windows, document folders, retention labels, and date-picker defaults. If another system requires timestamps, apply that system’s time-zone policy explicitly after receiving the result; do not assume that a date ending in December 31 automatically means the same final instant everywhere. For half-open timestamp ranges, a common downstream design is to use the returned first day as the inclusive lower date and separately derive January 1 of the following year as the exclusive upper boundary.
This capability intentionally returns the requested year’s actual last calendar day because that is the search intent and is clearer for human-facing schedules. It does not calculate fiscal years, academic years, rolling twelve-month periods, business days, or the current year. Those concepts need additional rules that cannot be inferred from one ISO date.
What you can do with it
Annual reporting filters
Turn any dated transaction into inclusive January 1 and December 31 boundaries for a consistent calendar-year report query.
Archive and folder naming
Derive stable annual archive bounds from a record date without relying on the machine’s current year or time zone.
FAQ
Does the calculator use the current year?
No. It requires an explicit ISO date and uses only the year contained in that input, so the current clock cannot affect the answer.
What format does the date require?
Use strict YYYY-MM-DD with fixed-width components, such as 2024-06-15. Timestamps, slashes, abbreviated components, and impossible dates are rejected.
Does a leap year change the returned boundaries?
No. Leap years add February 29 between the boundaries.
Are the first and last day included in the range?
Yes. Both January 1 and December 31 belong to the range, so you can use them directly in a from-and-to filter that includes both ends, without adding or removing a day.
How should I use these dates with timestamps?
Treat them as calendar days, not exact moments, and apply your own time zone rule. If you need a range that stops just before the next year, use January 1 of the following year as the end.
Related tools
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/year-start-end \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"date":"2024-06-15"}'const res = await fetch("https://api.kit.forhosting.com/date/year-start-end", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"date": "2024-06-15"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/date/year-start-end",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"date": "2024-06-15"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/date/year-start-end", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"date":"2024-06-15"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"date":"2024-06-15"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/date/year-start-end", 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": "2024-06-15"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "date.year_start_end",
"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. |
Technical notes
How the year boundaries are derived
The leap calculation determines whether days_in_year is 365 or 366 and supplies the is_leap_year flag. This approach never asks what date it is now.
Input validation and response fields
A successful response echoes the validated date and includes year as an integer. The first_day and last_day fields are inclusive ISO calendar dates, making them ready for range filters that use greater-than-or-equal and less-than-or-equal comparisons. The response additionally includes is_leap_year and days_in_year, which help callers size annual schedules or confirm leap handling without running a second calculation. Invalid input becomes an invalid_input error with a concise explanation instead of silently rolling into another month or year.
Using calendar-year bounds safely
Treat first_day and last_day as civil dates rather than instants. A successful API request costs $0.002 per item, while the browser tool can perform the same pure calculation locally. Because there is no network access, clock lookup, randomness, or hidden locale state, repeating an input always returns the identical JSON result.
Integration use cases
Calendar regression tests
Generate predictable year limits and leap metadata for fixtures covering ordinary years, leap years, and century exceptions.
Technical questions
Are the first and last days inclusive?
Yes. first_day is January 1 and last_day is December 31 of the input date’s calendar year, and both belong to that year.
What does an API request cost?
A successful API request costs $0.002 per item. The browser version runs the same deterministic calculation locally for free.