This only affects dates with no zone. A timestamp, or a date ending in "Z", does not depend on it.
The common ones are suggested, but any IANA name works: Asia/Tokyo, Pacific/Auckland, Africa/Nairobi and so on.
The date
—
Formats
The same instant, by zone
How to use it
01
Paste whatever you have
A ten or thirteen digit number, an ISO date, one with slashes, or whatever an API handed you. It is detected automatically.
02
Pick the zone
What you type is interpreted in the zone you choose, and that is what decides whether it is nine in the morning or four.
03
Copy the format you need
Every value copies with one click, and the same instant shows across every zone you add.
The formats you will run into
Five ways of writing the same moment. The difference between them is not cosmetic: two of the five do not say which zone they are in, and that is where the hours get lost.
- ISO 8601
- The format to use between systems: 2026-08-20T14:00:00Z. It sorts alphabetically the same way it sorts chronologically, and the Z — or the offset — removes any doubt about the zone.
- Unix timestamp
- The seconds elapsed since 1 January 1970 in UTC. It carries no time zone because it needs none: it is an instant, and the zone only appears when you display it.
- RFC 2822
- The one in email headers and many RSS feeds: Thu, 20 Aug 2026 09:00:00 -0500. Its names are always in English, whatever language the message is in.
- SQL
- 2026-08-20 09:00:00, with no zone. This is the one that causes migration trouble: the same string means a different moment depending on each server configuration.
- Day/month/year
- The everyday format in most of the world, and the one that breaks imports: 03/04 is 3 April in Europe and 4 March in the United States. Never use it to exchange data.
The rule that prevents half the bugs
Always store the instant in UTC — or as a timestamp, which is the same thing — and convert to each person’s zone only when displaying it. The moment a local time enters the database without its offset, the information about which instant it was is already lost and no query will bring it back.
The exception is dates that are not instants: a birthday or an invoice date is a calendar day, not a moment, and converting those between zones is exactly what shifts them by a day. Store those as bare dates and leave them alone.
Frequently asked questions
How do I know whether my number is in seconds or milliseconds?
By the digit count. A timestamp in seconds has ten digits from 2001 until 2286; one in milliseconds has thirteen. This tool works it out and says out loud what it assumed, because getting it wrong is expensive: reading milliseconds as seconds throws the date to the year 55,000, and the other way round pins it to January 1970.
Does a timestamp carry a time zone?
No, and that is the beauty of the format: it is the number of seconds since one specific instant, 1 January 1970 at midnight UTC. The same number is the same instant everywhere on the planet. The zone only enters when you display it, which is exactly what the zone table on this page does.
What is the year 2038 problem?
Systems storing the timestamp in a signed 32-bit integer run out of room on 19 January 2038, and the counter overflows into negative numbers: 1901. Any modern system uses 64 bits and is unaffected, but embedded devices and old databases with 32-bit columns are still out there.
Why does my date show a day earlier than expected?
Almost always the zone. A date with no time is often interpreted as midnight UTC, and in any zone west of Greenwich that midnight is still the previous day. It is why a birthday stored as a bare date shows up shifted by one day for half the staff.
Are my dates sent to a server?
No. The conversion, the formats and the zones are all computed in your browser with the date functions it already ships with. There are no network requests, nothing is stored, and this site uses no tracking cookies.
Where do the time zones and their daylight saving rules come from?
From the browser itself, which includes the IANA time zone database and updates it with every release. That is why the offsets you see account for daylight saving on that specific date rather than today: the same country can be five or six hours away depending on the month.
Can I type "31/12/2026 23:59"?
Yes. Slashes, dashes and dots are accepted, with two or four digit years and optional time. It is always read as day/month, and when the day is 12 or lower the tool warns you that the same string could be read the other way round by another system.
Dates that disagree between two systems?
When two applications exchange dates without agreeing on the zone, the drift stays invisible until somebody complains. It is one of the things we check when integrating systems, and one of the cheapest to fix beforehand.
We reply within one business dayBogotá · UTC−5