Inclusive or Exclusive? The Fencepost Problem in Every Date Count
Ask two people how many days there are from Monday to Friday and you may get two answers: 4 if you count the gap, 5 if you count the days themselves. Neither is wrong — they are answering different questions. Mathematicians call this the fencepost problem: a fence with 5 posts has only 4 sections between them. Nearly every dispute about a date calculation traces back to whether the first day is included.
Exclusive counting (end minus start) is what this tool computes, and it is the right model for elapsed time: hotel nights, interest accrual, and "how many days until my exam" all count the gaps, not the endpoints. A stay checking in on the 10th and out on the 13th is 3 nights, even though it touches 4 calendar dates.
Inclusive counting adds one, and it is the right model whenever both endpoints are "used": rental car days, medication courses ("take for 7 days starting today"), and event durations. Korean law formalizes the split: the Civil Code's 초일불산입 principle (Article 157) excludes the first day when computing legal periods, so a 30-day notice served on March 1 starts counting from March 2 and expires at the end of March 31. Yet everyday Korean customs go the other way — a baby's 백일 (100th-day celebration) counts the birth date itself as day 1, which is why it lands 99 days after birth by exclusive arithmetic. When a contract deadline, visa window, or return period matters, do not guess: check which convention the document uses, then add or do not add the one day deliberately.
Monday -> Friday, same week:
Exclusive (end - start): 4 days "days between"
Inclusive (end - start + 1): 5 days "days covered"
Hotel: check-in 10th, check-out 13th
nights = 13 - 10 = 3 (exclusive: correct)
Korean legal notice (Civil Code Art. 157, first day excluded):
30-day notice served Mar 1
count starts Mar 2 -> period ends Mar 31 (24:00)
Baby's 100th day (baek-il, birth date = day 1):
born Jan 1 -> day 100 = Jan 1 + 99 days = Apr 10 (non-leap year)Leap Years and Unequal Months: Why the Calendar Refuses to Be Simple
A tropical year — one full trip of Earth around the Sun — lasts about 365.2422 days, and that awkward fraction is the root of every calendar complication. The Julian calendar of 45 BC patched it with a leap day every 4 years, overshooting by roughly 11 minutes per year; by the 16th century the accumulated drift had pushed the equinox 10 days off. The Gregorian reform of 1582 fixed the rule to the one we use now: a year is a leap year if divisible by 4, except century years, unless divisible by 400. So 2000 and 2024 are leap years, while 1900 and 2100 are not. The residual error is about one day in 3,300 years.
This matters for date arithmetic in two concrete ways. First, any span crossing February 29 is one day longer than the same-looking span in a common year: January 15 to March 15 is 59 days in 2025 but 60 days in 2024. Second, "one month" and "one year" are not fixed quantities — months run 28 to 31 days, and adding "one month" to January 31 has no obvious answer (most software clamps to February 28 or 29).
This tool sidesteps the ambiguity by keeping day counts exact while treating weeks, months, and years as quick approximations: weeks are days divided by 7, months days divided by 30, years days divided by 365. That is ideal for estimation, but for legally exact calendar months or precise age in years-months-days, use the dedicated age calculator, which walks the real calendar instead of dividing.
Gregorian leap year rule:
divisible by 4 -> leap (2024 yes)
...but by 100 -> common (1900, 2100 no)
...but by 400 -> leap (2000 yes)
Same-looking span, different length:
2025-01-15 -> 2025-03-15 = 59 days (common year)
2024-01-15 -> 2024-03-15 = 60 days (crosses Feb 29)
"Add one month" is ambiguous:
Jan 31 + 1 month = Feb 28? Feb 29? Mar 2/3?
(most software clamps to the last day of February)Midnight, Time Zones, and the Missing Hour: Where Day Counts Go Wrong
A "day" feels like the most solid unit imaginable, but software usually implements it as 86,400 seconds — and that assumption quietly breaks. In regions that observe daylight saving time, one day each spring lasts only 23 hours and one each autumn lasts 25. A program that adds 30 × 86,400 seconds to a spring date in New York or Berlin can land at 23:00 on the previous calendar day, off by one from what any human would answer. Korea, Japan, and China do not currently observe DST, which is one reason date bugs surface mostly in code written for or by users elsewhere. Robust software adds days on the calendar, not on the clock.
Time zones create a second trap. The same instant is Tuesday in Seoul and still Monday in Los Angeles, so "days until launch" legitimately differs by one depending on where you ask. This tool uses your device's local midnight as the day boundary, which matches human intuition — but if you compare its countdown against a server, an app, or a friend abroad, a one-day disagreement usually means a time-zone difference, not a bug.
There is also a subtle programming wrinkle worth knowing: in JavaScript, a bare date string like 2026-07-02 is parsed as midnight UTC, while the current time is local. For users east of Greenwich the local clock is already past UTC midnight, and naive subtractions can drift by several hours. The practical takeaway is the same in every language: anchor both endpoints to the same convention — both local midnights or both UTC — before subtracting.
ISO 8601: The One Date Format That Never Gets Misread
What date is 03/04/05? An American reads March 4, 2005; a Brit reads 3 April 2005; and in Korea, Japan, or China the natural reading is April 5, 2003, because East Asian convention runs year-month-day. Every one of those readings is locally correct, which is exactly the problem — dates written in slash formats are ambiguous the moment they cross a border, an email thread, or a filename.
ISO 8601, the international standard, resolves this by mandating largest-unit-first with fixed widths: YYYY-MM-DD, so 2026-07-02 can only mean July 2, 2026. The design has a bonus property engineers love: because the components are ordered by significance and zero-padded, plain alphabetical sorting of ISO dates is also chronological sorting. Name your files 2026-07-02-report and they line up in date order in any file manager with no special logic. The standard also defines week numbering (the famous "week 27"), durations, and combined date-times with time-zone offsets.
East Asian date order matches ISO almost by accident of tradition — 2026년 7월 2일 and 2026年7月2日 are already year-month-day — which is why the format feels natural in Seoul and Tokyo but took decades to spread in the US. The date pickers on this page read and write ISO format under the hood, as do HTML date inputs everywhere. Practical habit worth adopting: whenever a date leaves your head for someone else's — contracts, tickets, spreadsheets, file names — write it ISO style or spell out the month, and the ambiguity disappears entirely.
The same string, three readings:
03/04/05 -> Mar 4 2005 (US) | 3 Apr 2005 (UK) | 2003 Apr 5 (East Asia)
ISO 8601 is unambiguous AND sorts correctly:
2026-07-02-notes.txt
2026-07-10-notes.txt
2026-11-03-notes.txt <- alphabetical = chronological
Compare non-ISO file names (alphabetical order, WRONG chronology):
02-07-2026.txt
03-11-2026.txt
10-07-2026.txtWorked Examples and the Mistakes People Actually Make
The fastest way to build date-arithmetic intuition is to work a few real cases end to end. Project deadline: a contract signed on 2026-07-02 with a 90-day delivery window. Exclusive counting from the signing date lands on 2026-09-30 — use the add-days panel with +90 to verify, and note that July and August both having 31 days is what keeps the result in September. Visa math: a 90-days-per-180 rule (used by the EU's Schengen area) is a rolling window, so this tool can count days between entry and exit, but you must sum multiple stays yourself. Salary anniversary: someone hired 2024-02-29 has a start date that exists only every four years; HR systems typically credit February 28 in common years.
The recurring mistakes are worth naming. Off-by-one from mixing conventions: booking 7 hotel nights but blocking 8 calendar days off work, or the reverse. Weekday drift: shifting a date by exactly n weeks never changes the weekday (7 divides evenly), so if your "+28 days" result lands on a different weekday than the start, the input was wrong. Business-day confusion: this tool counts every calendar day; a "10 business day" shipping promise spans at least 14 calendar days and more with holidays, which differ by country — Chuseok, Golden Week, and Thanksgiving all move or cluster differently. And month approximation: the months figure here divides by 30, so 365 days shows as 12 months and 5 days' worth of remainder is folded away — fine for planning, but for a rent contract measured in calendar months, count on the calendar itself.
Contract: signed 2026-07-02, deliver within 90 days
Jul 3..31 = 29 days
Aug = 31 days (running total 60)
Sep 1..30 = 30 days (running total 90)
-> due 2026-09-30
Sanity check with weeks:
+28 days = exactly 4 weeks -> SAME weekday as start
(different weekday? re-check your input)
Business days vs calendar days:
"10 business days" >= 14 calendar days (2 weekends)
+ national holidays (Chuseok / Golden Week / Thanksgiving...)