Methodology

All time zone conversions use Luxon, a JavaScript date/time library that uses the runtime’s Intl timezone support, based on the IANA Time Zone Database (also known as the tz database or Olson database). The IANA database is the authoritative source for civil time zone rules worldwide and is updated several times per year by the Internet Assigned Numbers Authority.

When you add a city, TimezoneCast uses its IANA zone identifier (e.g. America/New_York) to compute the exact UTC offset at any given instant. Offsets are recomputed for each point in time shown on the grid — not cached from a static table.

DST transitions are handled automatically by Luxon using the IANA database. There is a distinction between city zones and fixed offsets: city zones follow seasonal rules; a named fixed offset such as EST (UTC−5) or GMT (UTC+0) does not change with DST.

On the converter pages (e.g. /est-to-pst), DST status is computed at the time the page is generated. Cached pages become eligible for regeneration after 60 seconds. Regeneration happens on a later request, so reference content is not guaranteed to be less than one minute old.

Upcoming DST transition dates shown on pair pages are found by stepping forward day by day and checking for a change in DST state at noon. These are calendar-date estimates, not exact transition instants. Use a date-aware timezone source for overnight scheduling around a clock change.

EST always means UTC−5 and PST always means UTC−8. Those are valid fixed-offset conversions. The mistake is treating a city such as New York or Los Angeles as if it used its standard-time offset throughout the year. In summer, those cities use EDT (UTC−4) and PDT (UTC−7).

The same applies to London: GMT (UTC+0) is the UK's winter time; from late March through late October the UK is on BST (UTC+1). A fixed-GMT converter misrepresents London for more than half the year.

Abbreviation pages give a fixed-offset answer first. The separate city planner and reference sections use the cities’ seasonal local times. For example, 9 AM SGT is 1 AM GMT, while it is 2 AM in London when London observes BST.

Why EST and EDT are different — and when each applies →

Time zone abbreviations like EST, CST, and IST are not globally unique. For example:

• ·EST means UTC−5 in North America but is sometimes used informally for Australia Eastern Standard Time (UTC+10)
• ·IST means India Standard Time (UTC+5:30), Irish Standard Time (UTC+1), and Israel Standard Time (UTC+2)
• ·CST means Central Standard Time (UTC−6), China Standard Time (UTC+8), and Cuba Standard Time (UTC−5)

The city planner anchors conversions to IANA zone identifiers. Fixed-abbreviation answers use the explicitly stated UTC offsets. Ambiguous abbreviations are explained beside the answer: CST means US Central Standard Time and IST means India Standard Time on the corresponding pages.

The meeting suitability table on each converter page shows 24 hourly slots starting from midnight in the origin time zone. For each slot, TimezoneCast checks whether both cities fall within a defined window:

• ·Green (✅ Ideal) — both cities between 9:00 AM and 5:59 PM local time
• ·Yellow (⚠️ Possible) — both cities between 8:00 AM and 6:59 PM local time (edge hours)
• ·Gray (❌ Outside hours) — at least one city is before 8 AM or at/after 7 PM

These thresholds (9 AM–6 PM core, 8 AM–7 PM edge) are intentionally generous. Many teams work outside standard hours. The table is a starting point, not a mandate.

When you click the ICS button in the interactive planner, TimezoneCast generates an one-off .ics file through its server endpoint. The event is stored as a UTC instant so calendar applications can display it in the attendee’s timezone. Compatible with Google Calendar, Outlook, Apple Calendar, and any other application that reads .ics files.

The selected event and city setup are sent to the TimezoneCast server to generate the download. The export is a single event; configure any recurring series and its anchor timezone in your calendar application.

• ·Historical time zone data before 1970 is incomplete in some IANA entries. TimezoneCast is designed for present and near-future scheduling, not historical research.
• ·The IANA database occasionally has errors for remote or disputed territories. If a city looks wrong, please report it.
• ·Fixed UTC offset zones (e.g. UTC+5:30) do not observe DST by definition. If you add a fixed offset, the time will not change during DST transitions.
• ·Reference meeting tables use the stated reference date. Use the interactive planner for the actual meeting date; moving it does not change the reference content below it.
• ·Browser timezone detection uses the browser's configured timezone. If your browser's system clock is wrong, displayed times will be wrong.

If you find a DST date that looks wrong, an offset that seems off, or a city that maps to the wrong time zone, please send a report. Include the city or pair in question, the date you noticed it, and what you expected to see. Corrections are verified against the IANA database and fixed as quickly as possible.