Free Online Date & Time Calculators
Add or subtract days from a date, measure the difference between two dates, convert Unix timestamps and view the time in localized world formats.
Add or subtract days, weeks, months and years from any date and get the exact resulting date, weekday and day-of-year. Free date calculator.
Work out an exact age in years, months and days from a birth date, or measure the difference between any two dates. Free age and date difference tool.
See the current date and time rendered in dozens of locale formats side by side, with the ICU pattern behind each one. Free online reference tool.
Convert a Unix epoch timestamp to a human date and time in any timezone, and turn a date back into a timestamp in seconds or in milliseconds.
Date arithmetic is harder than it looks
Adding a month to a date has no single correct answer. What is 31 January plus one month? Most systems say 28 February (or 29 in a leap year), some say 3 March, and both are defensible. Adding days is unambiguous; adding months and years is a convention. The date calculator clamps to the end of the target month, which is the behaviour PHP, JavaScript's Temporal API and most databases share — but it is worth knowing that a different tool may give you a different date and neither is broken.
What each tool is for
| Question | Tool |
|---|---|
| What date is 90 days from today? What was 18 months ago? | Date Add & Subtract |
| How old is someone exactly? How many days between two dates? | Age & Date Difference |
| What does 1735689600 mean as a date? | Unix Timestamp Converter |
| How would this date be written in Germany, Japan or Saudi Arabia? | Localized Date Formats |
Age is not elapsed days divided by 365
The age calculator works in calendar units, not fractions of a year, because that is how people and legal systems count age. Someone born on 29 February has a legal birthday of 28 February or 1 March depending on jurisdiction, and dividing days by 365.25 gets that wrong for everyone. Calendar arithmetic walks whole years, then whole months, then remaining days — which is why the result reads "34 years, 7 months, 12 days" and not "34.61 years".
Unix timestamps: seconds, milliseconds, and 2038
A Unix timestamp counts seconds since 00:00:00 UTC on 1 January 1970. Three practical things follow from that definition.
- It is always UTC. A timestamp has no timezone; the timezone is applied when you format it for display. This is a feature, not a limitation — storing timestamps and formatting per user is the correct way to handle a global audience.
- Seconds or milliseconds? Unix, PHP and databases use seconds; JavaScript's
Date.now()uses milliseconds. A timestamp of 10 digits is seconds and lands in the current era; 13 digits is milliseconds. Feeding milliseconds to a seconds-based parser gives you a date somewhere around the year 55,000, which is the usual symptom. - The 2038 problem is real but mostly solved. A signed 32-bit timestamp overflows on 19 January 2038. Modern 64-bit systems and PHP 8 use 64-bit integers and are unaffected; embedded systems and old database columns may not be.
Date formats are a genuine source of bugs
03/04/2026 is 3 April in most of the world and 4 March in the United States. There is no way to tell from the string itself. This ambiguity has caused real incidents in shipping, medicine and finance, and the fix has been standardised for decades: ISO 8601, written 2026-04-03, year first, always unambiguous, and it sorts correctly as plain text.
Use ISO 8601 for anything a machine will read, anything stored, and anything crossing a border. Use localized formats only for display to a human whose locale you know. The localized formats tool shows the current moment rendered in dozens of locales side by side, with the ICU pattern behind each one, so you can see how wide the variation really is — including calendars that are not Gregorian at all.
A note on timezones and DST
Timezone offsets are not fixed: they change twice a year in many countries, and governments change the rules themselves with little notice. Never store an offset; store UTC and a timezone identifier such as Europe/London or Asia/Dhaka, and let the IANA database resolve it at display time. An event stored as "14:00 +01:00" becomes wrong the moment the rules change; the same event stored as UTC plus a zone identifier stays correct.