How 'Days Ago' and 'Days From Now' Are Calculated, Including Leap Years

30 days before 15 March 2028 is not 13 February. It is 14 February. Shift the same calculation back two years to 15 March 2026 and the answer does land on 13 February. The difference is a single day tucked into February 2028, a leap day that trips up anyone who treats all years as identical lengths. Date arithmetic looks like simple subtraction, but the calendar folds time unevenly. Getting the right date means knowing exactly which unit you are counting and what the calendar does with it.

Counting pure days is the most reliable operation in date work. You take a start date and move backward or forward one day at a time. A time calculator that works in day units simply subtracts or adds an integer. No months, no years, no hours. Just days. That is why the answer changes when a leap day sits inside the interval. Between 13 February 2028 and 15 March 2028 there are 31 days, not 30. The extra day is 29 February. To land exactly 30 days before 15 March 2028, you must step over that leap day and stop on 14 February.

The Gregorian calendar embeds a precise rule for those leap years. A year is a leap year if it is divisible by 4. But if it is divisible by 100 it is not a leap year, unless it is also divisible by 400. The year 2000 cleared all three hurdles and was a leap year. The year 1900 failed the 400 test and stayed a common year. The year 2100 will do the same. That rule is the only reason the gap between two dates stays predictable over centuries. When you ask what date was 30 days ago or what date falls 90 days from now, the answer depends on whether a 29 February lies in the path. Whether a 29 February sits inside the interval decides the answer.

The leap year trap

A day count across February in a leap year always shifts the result by one compared with a common year. The shift is not a bug. It is the calendar doing exactly what the Gregorian rule demands. The trap is that people remember the rule for years but forget to check whether the interval actually crosses 29 February. An interval of 60 days that starts in January 2028 will include the leap day. The same interval starting in March 2028 will not. The arithmetic is the same. The calendar under it is not.

Software that counts days correctly must test the full date range, not just the year of the start or end date. A 2026 calendar shows a standard February of 28 days. A 2028 calendar shows 29. When a tool only checks the start year, it can miss a leap day that sits in the middle of the span. That is how a person asking for "90 days from 1 January 2028" can be given a date that is one day early. The count of 90 days is right. The calendar model was wrong.

The month trap

Months break the simplicity. A month is not a fixed unit. It can be 28, 29, 30 or 31 days long. Asking for "one month after 31 January" is an underspecified question. There is no single right answer because a month is not a measurement. It is a calendar position. Some systems map 31 January plus one month to 28 February in a common year or 29 February in a leap year. Others roll forward into March, returning 3 March or another date. The variation is not a rounding error. It is a design choice.

This matters whenever a date tool offers a month mode. The user sees "one month" and expects a consistent rule. The tool applies whatever convention its makers chose. The results diverge silently. Two different apps can give two different dates for the same input, and both can claim to be correct. The only way to avoid the ambiguity is to convert the question into days. If you need a date a fixed duration away, count the days. If you need the same day number in a different month, accept that some months do not have that day.

The daylight saving trap

A calendar day is not always 24 hours. On a day when clocks spring forward, the day lasts 23 hours. When they fall back, the day stretches to 25 hours. This matters as soon as someone mixes "24 hours from now" with "the same time tomorrow." The two phrases point to different moments.

Add 24 hours to a time just before the clocks spring forward and the result reads an hour later than "the same time tomorrow", because the clock skipped an hour on the way. In autumn the day lasts 25 hours, and 24 hours later reads an hour earlier. Same duration, different wall-clock answer.

Date tools that work in calendar days ignore this. They increment the date and keep the clock time unchanged. That matches what most people mean by "tomorrow at this time." But a tool that works in exact hours will drift by an hour across a daylight saving transition. Neither answer is wrong. They answer different questions. The mistake is using one when you meant the other.

The safe approach is to separate the two questions completely. For dates, count in days. That means ignoring hours, ignoring time zones, ignoring daylight saving. Pick a start date, add or subtract an integer number of days, and read the result off the calendar. For exact durations across hours, count in UTC. UTC has no daylight saving. An hour is always 60 minutes. A day is always 24 hours. If you need to know what time it will be exactly 72 hours from now, do the arithmetic in UTC and then convert back to a local wall clock time for display. That keeps the duration precise and the local time readable.

Mixing the two approaches creates the errors. A person who asks "what date is 90 days from now" and gets an answer that shifted an hour because of a time zone offset has been given an answer to a question they did not ask. A person who asks "what time will it be in 24 hours" and gets the same clock time tomorrow across a daylight saving boundary has been given an answer that is wrong by exactly one hour.

The arithmetic underneath is not hard. The hard part is knowing which arithmetic to use. Count in days for dates. Count in UTC for exact durations. Say which one you mean. That is the safe approach.