Zeitzonen-Konverter

Understanding Timezone Conversion

Timezone conversion is the process of translating a date and time from one geographic timezone to another, accounting for UTC offsets, daylight saving transitions, and historical rule changes. The IANA Time Zone Database (often called tzdata or the Olson database) is the authoritative source for timezone definitions, maintained collaboratively and used by virtually every operating system, programming language, and runtime environment. It catalogs over 500 timezone identifiers using the Area/Location naming convention — for example, America/New_York, Europe/London, or Asia/Tokyo. Each entry encodes the full history of UTC offset changes, DST transitions, and political boundary shifts for that location, enabling accurate conversions for both current and historical timestamps.

The IANA Timezone Database (tzdata)

The IANA Time Zone Database is updated multiple times per year to reflect legislative changes — countries frequently modify their DST rules or abolish daylight saving entirely. The database assigns each timezone a canonical identifier that encodes geographic and political context rather than relying on ambiguous abbreviations. For example, CST could mean Central Standard Time (UTC−6), China Standard Time (UTC+8), or Cuba Standard Time (UTC−5). The IANA identifier America/Chicago eliminates this ambiguity entirely.

Key characteristics of IANA timezone identifiers:

• Geographic precision: Each identifier maps to a specific geographic region with a single, unambiguous rule set at any point in time.
• Historical accuracy: The database preserves every past transition — including one-time wartime shifts, split-second leaps, and political reunifications.
• Forward stability: Existing identifiers are never removed or repurposed, only deprecated via link entries to newer canonical names.
• Regular updates: The database typically receives 3–10 updates per year (e.g., 2024a, 2024b) as governments announce DST changes.

When storing timestamps, best practice is to store the instant in UTC and the IANA timezone identifier separately. This allows accurate reconstruction of the local time even if the timezone rules change after the event was recorded — a common occurrence with recurring events like weekly meetings that span DST transitions.

Daylight Saving Time (DST) Transitions

Daylight saving time creates two critical edge cases for timezone conversions: the spring forward gap (where local times are skipped) and the fall back overlap (where local times occur twice). For example, when the US Eastern timezone springs forward at 2:00 AM on the second Sunday of March, the local clock jumps directly to 3:00 AM — the times between 2:00 and 2:59 AM simply do not exist on that date. Conversely, when clocks fall back at 2:00 AM on the first Sunday of November, the hour between 1:00 and 1:59 AM occurs twice.

Correct timezone conversion must handle these cases explicitly:

• Gap (spring forward): A requested local time that falls within the gap is invalid. Systems typically adjust it forward by the DST offset (e.g., 2:30 AM becomes 3:30 AM EDT).
• Overlap (fall back): A local time that falls within the overlap is ambiguous — it could represent either the first or second occurrence. Systems must choose a disambiguation strategy (typically "first occurrence" or "post-transition").
• Variable rules: Not all countries observe DST, and those that do use different transition dates and offset magnitudes. Some regions (like Arizona in the US or parts of Australia) opt out entirely.

The safest approach to avoid DST-related bugs is to perform all arithmetic and comparisons in UTC, converting to local time only for display purposes. This strategy eliminates gaps and overlaps entirely from your computation logic — they only manifest at the presentation layer where they can be handled with explicit user-facing disambiguation.

JavaScript Timezone APIs: Intl.DateTimeFormat and Temporal

JavaScript provides two primary mechanisms for timezone-aware formatting. The established API is Intl.DateTimeFormat, which accepts a timeZone option using IANA identifiers and formats the instant accordingly. The convenience method Date.prototype.toLocaleString() delegates to the same underlying engine. Both correctly resolve DST at the target timezone for the given instant.

The newer Temporal API (Stage 3 TC39 proposal, available in modern runtimes) provides first-class timezone support through Temporal.ZonedDateTime. Unlike the legacy Date object which only stores a UTC instant internally, ZonedDateTime explicitly carries both the instant, the calendar, and the timezone — making DST disambiguation, arithmetic across transitions, and round-trip serialization reliable without external libraries.

Common timezone conversion bugs in JavaScript:

• Using fixed offsets instead of IANA identifiers: Hardcoding UTC+5:30 works today but breaks if India ever adopts DST. Always use Asia/Kolkata.
• Parsing dates without specifying timezone: new Date('2024-03-10') is parsed as UTC at midnight, which is still March 9 in US timezones — a classic off-by-one-day bug.
• Arithmetic across DST boundaries: Adding 24 hours to a Date does not always advance by one calendar day when a DST transition occurs during that period.
• Assuming getTimezoneOffset() is constant: This method returns the offset for the specific instant, which varies across DST transitions for the host timezone.

UTC Offsets and Fixed-Offset Timezones

A UTC offset represents the difference between local time and Coordinated Universal Time, expressed as ±HH:MM. While offsets range from UTC−12:00 to UTC+14:00, not all offsets are whole hours — India uses UTC+5:30, Nepal uses UTC+5:45, and the Chatham Islands use UTC+12:45. These fractional offsets are fully supported by both the IANA database and JavaScript's Intl.DateTimeFormat.

Fixed-offset timezones (like Etc/GMT+5) are appropriate only for representing a specific instant's offset — never for recurring events or future scheduling. The IANA notation inverts the sign convention: Etc/GMT+5 represents UTC−5 (west of Greenwich), which confuses many developers. Prefer geographic identifiers (America/New_York) over fixed offsets in application code.

When transmitting timestamps across systems, the ISO 8601 format with explicit offset (2024-06-15T14:30:00-04:00) or the Z suffix for UTC (2024-06-15T18:30:00Z) ensures unambiguous interpretation regardless of the receiving system's locale configuration.

Code Examples

Converting between timezones in JavaScript

// Convert a UTC instant to multiple timezones using Intl.DateTimeFormat
const instant = new Date('2024-06-15T18:30:00Z');

const options = {
  year: 'numeric', month: '2-digit', day: '2-digit',
  hour: '2-digit', minute: '2-digit', second: '2-digit',
  hour12: false
};

// Format the same instant in different timezones
const nyTime = instant.toLocaleString('en-US', {
  ...options, timeZone: 'America/New_York'
});
// → "06/15/2024, 14:30:00" (UTC-4 during EDT)

const tokyoTime = instant.toLocaleString('en-US', {
  ...options, timeZone: 'Asia/Tokyo'
});
// → "06/16/2024, 03:30:00" (UTC+9, next day!)

const londonTime = instant.toLocaleString('en-US', {
  ...options, timeZone: 'Europe/London'
});
// → "06/15/2024, 19:30:00" (UTC+1 during BST)

// Get the UTC offset programmatically for any timezone
function getUtcOffset(timeZone, date = new Date()) {
  const formatter = new Intl.DateTimeFormat('en-US', {
    timeZone,
    timeZoneName: 'longOffset'
  });
  const parts = formatter.formatToParts(date);
  const tzPart = parts.find(p => p.type === 'timeZoneName');
  return tzPart?.value || 'Unknown';
}

console.log(getUtcOffset('America/New_York'));
// → "GMT-04:00" (during EDT)
// → "GMT-05:00" (during EST)

Timezone conversion with the Temporal API

// Temporal API — first-class timezone support (Stage 3)
// Available in modern runtimes (Deno, Node.js with --harmony flag)

// Create a timezone-aware datetime
const meeting = Temporal.ZonedDateTime.from({
  year: 2024, month: 3, day: 10,
  hour: 14, minute: 30,
  timeZone: 'America/New_York'
});

// Convert to another timezone — DST handled automatically
const inTokyo = meeting.withTimeZone('Asia/Tokyo');
console.log(inTokyo.toString());
// → "2024-03-11T03:30:00+09:00[Asia/Tokyo]"

// Arithmetic that respects DST transitions
const nextDay = meeting.add({ days: 1 });
// Correctly adds 1 calendar day even across spring-forward
console.log(nextDay.hour); // Still 14 (2:30 PM), not 15

// Detect DST offset for a given instant
const offset = meeting.offsetNanoseconds / 3_600_000_000_000;
console.log(offset); // -4 (EDT active on March 10)

Standards & Specifications

• IANA Time Zone Database — Authoritative source for worldwide timezone definitions, DST rules, and historical transitions
• RFC 3339 — Date and time format for internet protocols — profile of ISO 8601 with timezone offset requirements
• TC39 Temporal Proposal — Modern JavaScript date/time API with first-class timezone and calendar support (Stage 3)