An offset such as +01:00 says how far a clock is from UTC at one particular moment. A timezone such as Europe/Madrid is the set of rules that decides which offset applies on which date, past and future. They look alike in a log line, but only the timezone can answer "what will the offset be next July?", and only the timezone can survive a government changing its mind. If you store the offset where you needed the zone, that information is gone and cannot be recovered from the number.
What is the difference between an offset and a timezone?
An offset is a measurement. Madrid in January is +01:00; Madrid in July is +02:00. Same city, same zone, two offsets. The zone name is the thing that knows why: it holds the standard offset, the rule for when daylight saving starts and ends, and the history of every time those rules were different.
| Offset | Timezone | |
|---|---|---|
| Example | -03:00, +05:30 | America/Argentina/Buenos_Aires, Asia/Kolkata |
| Is a | number, valid for one instant | name of a set of rules |
| Changes with daylight saving | yes, the number itself changes | no, the name stays and the rules produce a new number |
| Can tell you the offset next month | no | yes, if the rules have not changed by then |
| Shared by several places | yes, many zones have +01:00 right now | no, one name per region with its own history |
Two places can share an offset today and still be different zones. Their clocks agree this week and disagree in spring, because one moves and the other does not. The offset cannot tell them apart. The name can.
Why can't you work out the zone from the offset?
Because the mapping only goes one way. Many zones have -03:00 at some moment; a single -03:00 reveals none of them. The abbreviations are worse: CST is used for US Central Standard Time, China Standard Time and Cuba Standard Time, and nothing in the three letters says which. Treat an abbreviation as decoration for a human reader, not as data.
The other direction works, but only for one date. Give a zone name and an instant and you get exactly one offset. Give an offset and you get nothing back about any other instant.
What does a zone know that an offset does not?
Everything a legislature has ever decided about clocks. Rules are written by governments, and governments change them, sometimes with weeks of notice. The United States lengthened daylight saving time starting in 2007. Mexico abolished it for most of the country in 2022. Argentina has been on -03:00 all year for years, while Europe/Madrid still swings between +01:00 and +02:00. Some zones sit off the hour: Asia/Kolkata is +05:30 and Nepal is +05:45.
Software does not hard-code these rules. It reads the IANA time zone database, which is updated several times a year precisely because the rules keep moving. An old phone or a server that was never patched can be wrong about a zone whose rule changed after its last update, and no code of yours can fix that except by updating the data.
That is also why the offset you get for a date far in the future is a forecast, not a fact. Take "9:00 in Madrid on 15 July 2031". Today's rules say +02:00. If they change before then, the same wall-clock time becomes a different instant.
When does an offset lose information you need?
Whenever the question is about a time that has not happened yet, or about a time on a wall clock rather than in a log. There are two different things a "time" can mean, and they want different storage.
- Something that already happened (a payment, a login, a log line). It is an instant. Store it as a UTC timestamp, or an ISO 8601 string with an offset. The offset is fine here, because the moment is fixed and nobody will ask you to recompute it.
- Something scheduled by a person (a meeting at 09:00, a flight, a shop that opens at 10:00). It is a wall-clock time in a place. Store the local date and time plus the zone name, and compute the instant when you need it.
Store the second kind as a UTC instant and you will be right until the rules change. Say you book a Tuesday 09:00 meeting in Madrid and save it as 07:00 UTC, because that is what the offset gave you in summer. If the meeting is in November, when Madrid is on +01:00, the calendar now shows it at 08:00 for everyone in Madrid. Nothing was wrong at the time of saving. The zone would have known; the offset could not.
Storing only the offset breaks the same way with recurring events. "Every Monday at 09:00, +01:00" is correct until the clocks go forward, and then it fires an hour off local time for half the year.
What goes wrong twice a year, and what does the local clock skip?
When clocks go forward, a stretch of local time does not exist. When they go back, a stretch happens twice. In a zone that moves at 02:00 in spring, 02:30 never appears on the wall clock that day. In autumn, 01:30 appears twice, an hour apart, with two different offsets.
So a local time without an offset can be invalid, or can name two instants. That is why "1 November 2026, 01:30, New York" is not enough to identify a moment on the days when the clocks change, and why databases that accept a local time with a zone name need a rule for those hours. It is also why a duration of "24 hours" and "one day" are not the same thing on those two dates, which is the same trap that makes counting the days between two dates depend on what you count.
What can the timestamp converter show, and what can it not?
Paste a timestamp into the Unix timestamp converter and the "ISO 8601 (local offset)" line gives the offset your device's zone had at that moment, next to the UTC line. Try one from January and one from July and the local offset changes while the zone does not. That is the difference in one screen, and nothing leaves the page.
What it does not do is important here. It has two zones only, yours and UTC, with no picker, so it cannot tell you what a moment is in Madrid unless you happen to be in Madrid. It shows the zone name of your device but does not let you enter one. And in the date-to-timestamp direction, it asks you for a local time with no offset, then uses your browser to resolve it. For the skipped and repeated hours above, it does not warn you that the time was invalid or ambiguous; the browser silently picks one reading. Checking a clock-change day is on you.
The same limit applies to old dates. Local times before 1970 depend on historical zone data that your browser may not carry in full, so a converted pre-1970 local time can be off. The UTC line is not affected.
What should you store?
- For an event that happened: a UTC timestamp. If you want the local view too, keep the zone name it happened in as a separate field, not baked into the time.
- For an event a person scheduled: the local date, the local time and the zone name, as three fields. Compute the instant at the last moment you can.
- For a date with no time (a birthday, an invoice date): a plain
YYYY-MM-DDand no zone at all. A Unix timestamp is the wrong type for it. - Never the three-letter abbreviation as data, and never an offset as a stand-in for a zone.
Store the offset in addition to the zone name if you want a record of what the offset was at the time. That is useful for audit trails. It is not a replacement for the name.
To see the difference for yourself, put one January timestamp and one July timestamp into the Unix timestamp converter and compare the local offset on each. Remember that it only shows your own device's zone and UTC, so it will not stand in for a proper zone picker.
If you want the other half of the story, what a Unix timestamp is explains why an instant needs no zone at all, which is exactly why a scheduled wall-clock time needs one stored beside it.
Frequently asked questions
What is the difference between a timezone and a UTC offset?
A UTC offset, such as +01:00, is a single number that says how far a clock is from UTC at one moment. A timezone, such as Europe/Madrid, is a named set of rules that decides which offset applies on each date, including daylight saving and any past changes. One zone produces different offsets during the year.
Should I store a timezone or an offset in my database?
It depends on what the time means. For something that already happened, store a UTC timestamp; an offset is optional. For something a person scheduled in a place, such as a meeting or a flight, store the local date and time together with the zone name, because the offset can change before the event happens.
Can I find the timezone from a UTC offset?
No. Many different zones share the same offset at any moment, and they can disagree at other times of the year. An offset only narrows the answer to a list of candidates. You need the zone name, or a location, to know the rules.
Why do timezone rules change?
Governments set them, and governments change them for energy, politics or economics, sometimes with little notice. Software reads the rules from the IANA time zone database, which is updated several times a year. A system that has not applied the latest update can be wrong about a zone whose rule changed recently.
Is EST or CST a timezone?
They are abbreviations, not identifiers. CST alone can mean US Central Standard Time, China Standard Time or Cuba Standard Time, and the letters do not say which. Use an IANA name such as America/Chicago for data, and treat the abbreviation as text for a human reader only.
Last updated September 29, 2026
