Abbreviations are ambiguous, and that is the usual mistake
Time zone abbreviations are not unique, and several of the most-used ones mean two different things several thousand miles apart.
- CST is US Central Standard Time (UTC−6) and also China Standard Time (UTC+8). Fourteen hours apart.
- BST is British Summer Time (UTC+1) and also Bangladesh Standard Time (UTC+6).
- IST is India Standard Time (UTC+5:30), Irish Standard Time (UTC+1) and Israel Standard Time (UTC+2).
- AST is Atlantic Standard Time (UTC−4) and Arabia Standard Time (UTC+3).
Every page on this site involving an ambiguous abbreviation says which one it means before it converts anything. If a meeting invitation says CST and you are not certain which continent it came from, ask.
Standard time and summer time are different zones
PST is UTC−8 and PDT is UTC−7. They are not the same zone with a setting; they are two zones, and much of the year the correct abbreviation for California is PDT rather than PST. Most people write PST year-round. The converter accepts both and tells you which one is actually in force on the date you pick.
The offset depends on the date, not just the zones
The gap between London and New York is five hours for most of the year, but for two weeks in March and one week in either late October or early November it is four or six, because the two regions change their clocks on different dates. Any conversion given without a date is guessing during those weeks. This converter always uses a date.
Worked example — a meeting across three zones
A 09:00 start in Los Angeles on 12 November 2026 is 12:00 in New York, 17:00 in London and 03:00 the following morning in Sydney. The workable overlap between Los Angeles and London on that date is roughly 08:00–10:00 Pacific, which is 16:00–18:00 in London. There is no overlap at all with Sydney business hours; someone has to take an evening or an early morning.
Where our data comes from
Zone rules come from the IANA time zone database, whose version and review date are shown on every zone page. Governments change these rules by legislation, sometimes at a few weeks' notice, so the version matters.
The convention, stated plainly
- Every conversion is for a date, not in general. There is no such thing as "the" offset between two zones. The gap between London and New York is five hours for most of the year and four or six for about three weeks of it, because the two regions change their clocks on different dates.
- Zone rules come from the IANA database. The live converter uses your own browser's copy, so a legislated change reaches the answer before we rebuild. The static figures on the pair pages are derived from the three daylight-saving rules the zones we cover actually use, with the database version and review date printed on each page.
- An ambiguous abbreviation is disambiguated before anything is converted. If you meant the other CST, the page will have told you which one it assumed.
The clock-change dates, and the weeks they break
The US moves on the second Sunday in March and the first Sunday in November: 8 March and 1 November in 2026, 14 March and 7 November in 2027. The EU moves on the last Sunday in March and the last Sunday in October: 29 March and 25 October in 2026, 28 March and 31 October in 2027. Australia moves in the opposite direction, starting on the first Sunday in October and ending on the first Sunday in April — 4 October 2026 and 5 April 2026.
Two consequences fall out of those dates. First, for about three weeks each spring the US-to-Europe gap is an hour smaller than usual, and for one week each autumn it is an hour larger; a recurring meeting set by wall-clock time in one zone silently moves in the other. Second, the US-to-Australia gap changes four times a year rather than twice, and briefly runs in a direction that surprises people, because the two hemispheres are on opposite halves of the cycle. India, Japan, Korea and China do not observe daylight saving at all, so their gaps with the US and Europe move whenever the other end changes and never when they do.
Worked example — scheduling a recurring call
A weekly call fixed at 16:00 London time is 11:00 in New York from late March to late October, 12:00 for the week or so at each end where the two regions are out of step, and 11:00 again through the winter. Fixing it at 11:00 New York time instead makes it 16:00 in London most of the year and 15:00 during the mismatch. Whichever end you anchor to, the other end moves; the only way to avoid it is to anchor to UTC and accept that both ends move. This is not a defect in anybody's calendar software — it is what having two independently legislated transition dates means.
Where other converters disagree
- They quote an average offset. A tool that says "PST is 8 hours behind UTC" without a date is right for four and a bit months of the year and wrong for the rest, because the zone is on PDT from March to November.
- They resolve an ambiguous abbreviation silently. CST is both US Central and China Standard — fourteen hours apart. A converter that picks one without saying so has a coin-flip error rate on that abbreviation.
- They use a stale database. Zone rules change by legislation, sometimes at a few weeks' notice. A converter with a two-year-old table is confidently wrong for the zones that changed.
- They convert a date-less time. Without a date there is no correct answer during a transition week, so a tool that does not ask for one is guessing.
The pairs people ask for most
Each of these has its own page, with the current offset, both zones' daylight-saving status, the next change date at each end, a conversion table and the business-hours overlap: PST to EST, EST to PST, CST to EST, UTC to EST, GMT to IST and EST to IST are the busiest. The full index of zone pairs has every combination we cover. Once both ends are in one zone, the time duration calculator will give you the elapsed time, and the methodology page sets out where our zone data comes from and how often it is reviewed.