Methodology & Accuracy

Every clock and conversion on TimeConvertor.net is powered by a small, tested engine. This page documents where the data comes from, the conventions at the tricky edges, and exactly what "accurate" means here.

The data source: IANA via your browser

Time zone rules — offsets, daylight-saving start and end dates, historical changes — come from the IANA Time Zone Database, the global authority that operating systems and programming languages ship. We access it through the browser's built-in Intl API rather than bundling a copy, which has a decisive advantage: live times can never be staler than your own browser's tz data, which updates with the browser. (The static standard/DST offset columns on the city pages are computed when the site is built and refresh with each site build.) Nothing here hard-codes an offset. The 55 cities we list are identified by their IANA zone names (for example America/New_York), never by ambiguous abbreviations.

Clock accuracy, honestly stated

Live clocks display your device's clock, mapped into each city's zone. Modern devices synchronize via NTP and are typically accurate to well under a second — but device clocks can be minutes off, so where possible we check yours against our own server (see the next section) and correct the display when it is seconds adrift. We make no atomic-time claim. When the check cannot run, every clock here is exactly as accurate as your device's clock — and the caption under the landing-page clock says so rather than pretending otherwise. Display updates are aligned to the top of each second.

How the clock check works

Shortly after a page with live clocks loads, your browser sends several timed requests to timeconvertor.net's own server — the same origin the page came from, whose clock is NTP-disciplined by the hosting infrastructure; no third-party time service is involved. For each round trip the browser records its own clock immediately before sending and immediately after receiving, and the server replies with its clock reading. The sample with the lowest round-trip latency is kept, because it leaves the least room for network delay to distort the comparison; the offset is then the server's timestamp minus the midpoint of that round trip, the standard NTP estimate. Typical precision is a few tens of milliseconds.

Two honesty rules govern what we do with the estimate. First, this is not atomic or legal timekeeping — it is a well-understood engineering estimate whose error can approach half the round-trip time on asymmetric connections, so verdicts deliberately speak in whole seconds and a clock within a second (or within the measurement's own uncertainty) is simply called accurate. Second, failure switches the feature off rather than degrading it silently: if the request errors or cannot run, clocks tick from the raw device clock exactly as described above, and the caption discloses that. When the check does find your clock seconds off, displayed times are corrected by the measured offset and the caption says so. Time-zone conversions and the Meeting Planner are unaffected either way — they operate on dates and times you select, not on the current instant.

Conversion conventions at the DST edges

• Offsets are evaluated for the exact instant being converted — never a fixed city-to-city table — so seasonal shifts and mismatched DST calendars come out right.
• Nonexistent times (the spring-forward gap — e.g. 2:30 AM on a night clocks jump from 2:00 to 3:00) are resolved deterministically to a nearby real instant rather than rejected.
• Ambiguous times (the fall-back hour that occurs twice) resolve deterministically to one of the two instants. Which duplicate — and whether a gap resolves forward or backward — can differ between zones; the result is always a real instant.
• DST detection compares an instant's offset with the zone's standard offset, taken as the smaller of its January and July offsets — correct in both hemispheres because DST always moves clocks forward.
• Unix timestamps follow the standard convention: seconds since 1970-01-01 00:00 UTC, ignoring leap seconds; values of 10¹² or larger are interpreted as milliseconds.

How the Meeting Planner scores a slot

The Meeting Planner tests every candidate start time (every hour, or every half hour) against every participant separately, for up to 12 people across a window of up to 14 days. Each participant carries their own time zone, preferred hours (default 9:00–17:00), acceptable hours (default 7:00–21:00), working days, and any dates they are unavailable.

Two of those are hard constraints: a slot that falls outside someone's acceptable hours, or on a date they marked unavailable, is rejected rather than scored — it never appears in the ranking at any position. Working days are a burden by default and can be made hard with a single switch. Everything else is measured as a burden, in points, dimension by dimension:

These numbers are ours. No standard, statute or research consensus establishes what an hour of somebody's evening is worth against a Saturday morning; we picked a scale where one point is roughly one minute of mild inconvenience and set the rest to trade off sensibly against it. They are published here, exported as named constants in the engine, and shown on every result, so the arithmetic can be argued with rather than trusted blindly. Weekend and non-working-day are reported separately and can stack — one is a calendar fact, the other is that person's declared schedule, and they are not the same claim.

The fairness policy: worst case before total

Among the slots that survive the hard constraints, the planner minimizes the maximum single participant's burden first, and only then the group total. A slot costing four people twenty minutes each therefore outranks one costing a single person their whole night, even though the second has a lower total — concentrating a large cost on one person is treated as worse than sharing a small one. Remaining ties break on the earlier instant, which makes the order fully deterministic: the same inputs always produce the same ranking. Optional participants never cause a rejection and never set the worst case; they contribute to the total, and a slot they cannot attend takes a flat penalty so the ranking does not quietly exclude them.

Every "why this slot" explanation on the results is derived from the scoring trace — the same numbers the comparison used, printed back. Nothing about the winner is narrated independently of the arithmetic, which is why the explanation cannot describe a reason the ranking did not actually use.

Holidays, days off, and rotation history

We ship no holiday database. Holiday calendars are national, regional, religious, and company-specific simultaneously, they move year to year, and a wrong one is worse than none — a planner that confidently books over Diwali or Eid has done more damage than one that never claimed to know. So unavailable dates are user-entered: you type the days a participant is out and they become hard constraints. The same reasoning applies to the working week, which is per participant rather than an assumed Saturday–Sunday weekend.

When a recurring series is planned, the rotation that spreads the burden across occurrences is computed for the request in front of us and encoded in the share link. There is no stored fairness ledger: nothing on this site remembers who took the awkward slot last month, because nothing on this site stores anything about you. The planner's honest claim is "here is a fair distribution across these N occurrences", not "here is what you are owed".

When no slot is feasible at all, the suggested relaxations are computed, not composed: each is read off the constraint that actually blocked the nearest-miss window, or verified by re-solving with one parameter changed, and each carries the specific instant it would unlock.

Calendar hand-off: URL templates, and the one outbound flow

The Meeting Planner offers three ways to get a chosen slot into a calendar, and it is worth being precise about what each one does. The .ics download is built in your browser and handed to you as a file; it is iCalendar, the open standard specified in RFC 5545, which Google Calendar, Apple Calendar, Outlook, Thunderbird and Fastmail all import. It is the universal option and the one we lead with. The invite text is a string assembled in the page and placed on your clipboard. Neither leaves your device.

The calendar links work by URL template: the event's title, its start and end instants in UTC, and a plain-text description are percent-encoded into a query string that the provider's own web app knows how to read. There is no vendor API involved, no OAuth, no access token, no key of ours, no server of ours, and no request made by this page — the link is inert markup until you click it. Because the instants are absolute UTC, the composer cannot open on the wrong time whichever zone the viewer's calendar is set to.

The honest part. Clicking a calendar link takes you to that vendor's website, and from that moment you are their visitor, not ours: their privacy policy, their cookies, their logging. The link carries the meeting title, the times and the participant breakdown with it, because that is what pre-fills the form. This is the only outbound flow the planner has, and it happens only when you choose it — so it is written down here rather than left to be discovered. We add no tracking of any kind to these links: no analytics parameters, no click redirect, no referral tag, nothing appended beyond the event fields themselves.

We ship only formats we have actually watched work. Neither Google nor Microsoft publishes a specification for these query strings — they are long-standing conventions, not contracts, and either vendor could change one without notice. Google's action=TEMPLATE form was opened in a browser and observed landing on a pre-filled event composer with the correct title, date and time, so that button ships. Microsoft's Outlook deeplink could not be confirmed the same way, so no Outlook button is shown: a calendar link that silently loses the time is worse than no link, and the .ics file already covers Outlook by the standard. That decision is recorded as a flag in the engine, not as a comment, so turning the button on requires someone to verify it first.

What these tools do not do

We do not predict future rule changes (jurisdictions occasionally change DST law with short notice — the IANA database follows reality, and your browser follows the database), we do not show historical times before 1900 or beyond 2200, and we do not account for leap seconds. We also deliberately omit cities whose clock changes are not seasonal — Morocco, for example, shifts around Ramadan — because our standard/DST labeling would misrepresent them; conversions for such zones still work correctly if entered by IANA name elsewhere, since offsets are always evaluated per instant. For legally critical timing — contracts, filings, launches — confirm against an official source.

Tested against known cases

The engine's automated tests pin the classic hazards: DST in both hemispheres (New York and Sydney, whose seasons invert), half-hour and 45-minute zones (India, Nepal), conversions that cross the calendar line in both directions, the nonexistent and ambiguous wall times around the 2026 US transitions, and Unix timestamp round-trips. The Meeting Planner's solver adds its own suite: each burden dimension against hand-computed cases, the fairness policy proved on a board where the lower-total slot deliberately loses, every hard-constraint rejection path, the Friday-in-Los-Angeles/Saturday-in-Sydney date-displacement case, solves on a spring-forward day, the relaxation suggestions checked by applying them, and the share link's backward compatibility with the previous URL format. The calendar hand-off is pinned the same way: exact expected URL strings for a fixed sample event, UTC stamping across a daylight-saving boundary, encoding of titles and descriptions containing spaces, ampersands, quotes, newlines and non-ASCII characters, and invite text for a three-person cross-date meeting asserted to name every participant's local time and local date. The worked examples in page copy are computed at build time by this same engine, so the copy cannot drift from the code. If you believe a result is wrong, see the contact page — confirmed issues are fixed in the engine and locked in with a new test.