How the Date/Time Converter works
The converter reads ISO 8601 dates (2024-07-01, 2024-07-01T09:00:00.250Z, 2024-07-01 09:00+02:00), RFC 2822 dates as used in email headers (Mon, 01 Jul 2024 09:00:00 +0000, including zone names such as GMT, EST or PDT) and Unix timestamps in seconds or milliseconds. If the input includes a UTC offset, that offset fixes the moment. If it does not, the date and time are read as wall-clock time in the source time zone.
Time zone rules come from your browser's built-in IANA time zone database (the Intl API), so daylight saving time and historical changes are applied for each date. To turn a wall-clock time into a moment, the converter tries the zone's offsets from a day before and a day after and keeps the ones the zone really uses at the resulting instant. When clocks go back and a time happens twice, the first occurrence is used and a note shows the second. When clocks go forward and a time never happens, it is moved forward by the length of the gap (02:30 becomes 03:30), and a note says so.
The difference section reports the elapsed time as total days, hours, minutes and seconds, and also as a calendar difference in years, months and days. The calendar difference steps whole months first; when a month is shorter, the day is clamped to its last day, so 31 January to 1 March 2024 is 1 month and 1 day.
How to use the Date/Time Converter
- Type a date and time, for example 2024-07-01 09:00, 2024-07-01T09:00:00Z, Mon, 01 Jul 2024 09:00:00 +0000 or 1719824400. Select Now for the current time or Load example to try a daylight saving case.
- Choose the source time zone. It is used when the input has no UTC offset of its own.
- Choose the target time zone. The results show the moment in the source zone, target zone, UTC and your own time zone, with UTC offsets and ISO 8601, RFC 2822 and Unix formats.
- To measure the time between two dates, fill in Start and End. The difference is shown in total days, hours, minutes and seconds, and in years, months and days.
- Select Copy next to a value to copy it.
Example
With source time zone America/New_York and target Europe/London, the input 2024-07-01 09:00 gives:
Source: America/New York Mon, 2024-07-01 09:00:00 EDT UTC-04:00 2024-07-01T09:00:00.000-04:00
Target: Europe/London Mon, 2024-07-01 14:00:00 GMT+1 UTC+01:00 2024-07-01T14:00:00.000+01:00
UTC Mon, 2024-07-01 13:00:00 UTC+00:00 2024-07-01T13:00:00.000Z
RFC 2822 (Europe/London) Mon, 01 Jul 2024 14:00:00 +0100
Unix seconds 1719838800The input 2024-03-10 02:30 in America/New_York does not exist (clocks jumped from 02:00 to 03:00), so it is read as 2024-03-10T03:30:00.000-04:00. The difference from 2024-01-31 09:00 to 2024-03-01 17:30 is 30.3541666666667 days, or 1 month, 1 day, 8 hours, 30 minutes as a calendar difference.
Common use cases
- Scheduling a meeting across offices in different countries.
- Turning a UTC timestamp from a server log into the local time of the user who reported a problem.
- Checking what happens to a scheduled job at a daylight saving time change.
- Converting dates between the ISO 8601 format used by APIs and the RFC 2822 format used in email and HTTP headers.
- Counting the days or hours until a deadline, or the length of a contract or subscription.
Frequently asked questions
Which date formats can I enter?
ISO 8601 dates such as 2024-07-01, 2024-07-01T09:00 and 2024-07-01T09:00:00.250+02:00; the form 2024-07-01 09:00; RFC 2822 dates such as Mon, 01 Jul 2024 09:00:00 +0000 (the weekday, seconds and zone are optional, and GMT, UTC, EST, EDT, CST, CDT, MST, MDT, PST and PDT are recognised); and Unix timestamps in seconds or milliseconds.
Is daylight saving time taken into account?
Yes. Offsets come from your browser's IANA time zone database for the exact date, so the same zone can show different offsets in summer and winter. Historical rule changes are included as far as the browser's database goes.
What happens to a time that does not exist or happens twice?
When clocks go forward, times in the gap (such as 02:30 on the day US clocks change in March) do not exist; the converter moves them forward by the length of the gap and shows a note. When clocks go back, some times happen twice; the first occurrence is used and the note shows the second.
Why is the source time zone ignored for some inputs?
If the input already contains a UTC offset (Z, +02:00, -0500 or a zone name like EST) or is a Unix timestamp, it identifies an exact moment, so no time zone is needed to read it.
How is the difference in years, months and days calculated?
Whole months are counted first, then the remaining days and time. If the start day does not exist in the end month, the last day of that month is used, so 31 January to 1 March 2024 is 1 month and 1 day. Dates without an offset are read in the source time zone. The totals in days, hours, minutes and seconds are based on the actual elapsed time.
Which dates are supported?
Typed dates can be from year 1 to 9999. Unix timestamps can go further, within the range of JavaScript dates.