Methodology
How Time gets time right.
How Time calculates: IANA time zones through the Temporal API, explicit handling of DST gaps and overlaps, documented calendar rules and exact timestamp arithmetic.
The time engine
Every calculation uses the Temporal API (via a standards-tracking polyfill), not the legacy JavaScript Date. Temporal keeps distinct types for an exact moment (Instant), a moment in a place (ZonedDateTime), a wall-clock date and time (PlainDateTime) and a calendar date (PlainDate), so a date is never accidentally shifted by your device's time zone.
Time zones come from the IANA Time Zone Database built into your browser. Offsets are never hard-coded: the offset for a city is looked up for the specific moment being calculated, so conversions on DST change days, historical dates and future dates use the rules in force at that time.
DST gaps and overlaps
When clocks spring forward, some local times don't exist; when they fall back, some local times happen twice. Time detects both and asks you to choose — the earlier or later moment — instead of silently shifting the result. Internal helpers that must pick (for example the edges of a working day that starts inside a DST gap) use Temporal's documented “compatible” rule, and the result is labelled.
Calendar rules
- Date difference counts calendar years, then months, then days, and separately the exact total days. The end date is excluded unless you include it.
- Adding months or years keeps the day of month when it exists; otherwise it clamps to the month's last day (31 January + 1 month = 28 or 29 February), and says so.
- Business days exclude your chosen weekend days and any holidays you add. Public holidays are not included unless you add them. Adding business days does not count the start date.
- Weeks follow ISO 8601: Monday first, week 1 contains the year's first Thursday.
- Durations between two moments are exact elapsed time — a day containing a DST change can be 23 or 25 hours long.
Meeting planner scoring
Working hours are interpreted in each participant's own time zone on the chosen date (overnight shifts are supported). An overlap is a window where everyone is inside their working hours. When no full overlap exists, Time suggests the slot with the least total time outside working hours, weighting minutes more than two hours outside someone's working day (the middle of their night) three times as heavily; ties prefer fewer affected people, then the earlier start.
Timestamps
Unix timestamps are parsed as exact integers (no floating-point rounding), with the unit detected by magnitude — seconds, milliseconds, microseconds or nanoseconds — and always shown so you can override it. Negative timestamps (before 1970) are supported. ISO 8601 input is parsed strictly and every part is explained; an offset like +05:30 is treated as an offset, not a time zone.
Testing
Time's automated tests check DST transitions for New York, Los Angeles, London, Sydney and Auckland across several years (and fixed-offset zones such as India and Japan) against an independent rule-based oracle, and the whole suite runs under eight different device time zones to prove results don't depend on where your computer is.
Known limits
- Time-zone rules are as current as your browser's built-in database. Governments occasionally change rules at short notice.
- Dates before the adoption of standard time use “local mean time” offsets from the database and are rarely meaningful for planning.
- The current time is your device clock. If your clock is wrong, “now” is wrong.
- Public holidays are not built in.
Sources
- IANA Time Zone Database (opens in a new tab)
- TC39 Temporal API documentation (opens in a new tab)
- RFC 3339 — Date and Time on the Internet (opens in a new tab)
- RFC 9557 — Date and Time with Additional Information (opens in a new tab)
- ISO 8601 — Date and time format (ISO) (opens in a new tab)
- POSIX — Seconds Since the Epoch (opens in a new tab)
Found something wrong? Email bsamjoel@gmail.com.