Skip to main content

Methodology

This page explains how TimezoneCast calculates times, handles edge cases, and where its limitations are. If something looks wrong, please report it.

1. How time is calculated

All time zone conversions use Luxon, a JavaScript date/time library that wraps 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.

2. Daylight saving time

DST transitions are handled automatically by Luxon using the IANA database. There is no manual override or static abbreviation table — the offset for a given zone at a given moment is always derived from the rule in effect at that moment.

On the converter pages (e.g. /est-to-pst), DST status is computed at the time the page is generated. Pages are regenerated at most every 60 seconds via Incremental Static Regeneration (ISR), so DST status shown reflects conditions within the last minute.

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 (not midnight, which avoids the two-hour window where clocks actually change). The date reported is the calendar date of the first day where DST is different from today.

3. Time zone abbreviation ambiguity

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)

TimezoneCast always anchors conversions to an IANA zone identifier, not an abbreviation. The abbreviations shown in the UI (EST, PST, CET, etc.) are display labels only — the actual offset is always computed from the underlying IANA zone. When DST is active, the live clock components show the DST abbreviation (e.g. EDT instead of EST).

4. Meeting window calculation

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 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.

5. Calendar invite (.ics) export

When you click the ICS button in the interactive planner, TimezoneCast generates an RFC 5545-compliant .ics file in the browser. The event is stored in UTC with a TZID annotation for the anchor city's time zone. Compatible with Google Calendar, Outlook, Apple Calendar, and any other application that reads .ics files.

No server is involved in generating .ics files — the file is built and downloaded entirely in your browser.

6. Known limitations

  • ·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.
  • ·The meeting suitability table uses today's current offset, not future offsets. If DST changes between now and a meeting date, recalculate on that date.
  • ·Browser timezone detection uses the browser's reported locale. If your browser's system clock is wrong, displayed times will be wrong.

7. Reporting corrections

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.