Use a city zone and a full date
“New York at 9 AM” is not enough to schedule a meeting with Shanghai. The offset can change with the date. OmniKit uses named time zones and the selected date to calculate the conversion, rather than assuming that the difference is always the same number of hours.
These outputs were verified against the current tool function on 5 September 2026 using Node’s Intl time-zone data. Your browser supplies its own time-zone database; keep it updated if governments change local rules.
| Source date and time | From → to | Result |
|---|---|---|
| 2026-01-15 09:00 | America/New_York → Asia/Shanghai | 2026-01-15 22:00 |
| 2026-07-15 09:00 | America/New_York → Asia/Shanghai | 2026-07-15 21:00 |
| 2026-09-05 00:30 | Asia/Shanghai → America/Los_Angeles | 2026-09-04 09:30 |
In the first two examples, the same 9 AM meeting becomes a different evening time. In the third example, the destination is on the previous calendar day. Copying only the converted clock time would lose information that matters.
When a local time never happens
Try 2026-03-08 02:30 with America/New_York as the source. The tool reports that this local time does not exist. During the spring transition, the clock skips that range; it would be misleading to silently treat the input as a normal 02:30.
For a real appointment, ask the organizer for a valid time or a timestamp with an explicit UTC offset. Changing the hour until the tool accepts it would change the appointment rather than clarify it.
When the clock shows the same time twice
During the autumn transition, 2026-11-01 01:30 in New York can refer to two different instants. The current OmniKit converter returns one occurrence and does not offer a first/second occurrence selector.
For a repeated local time, obtain the original timestamp or its explicit offset and use a timestamp-based record to confirm it. The current local-time form is not suitable for choosing between the two occurrences.
A reliable way to share the result
- Enter the date as written by the sender and choose the sender’s city zone.
- Select the recipient’s zone. Read the date, clock time, and UTC offset in the result.
- For recurring meetings, convert dates on both sides of a seasonal change.
- Share the complete date and zone with the invitation. For skipped or repeated times, clarify the original instant before scheduling.
Implementation background: MDN Intl.DateTimeFormat. The examples describe OmniKit’s current behavior; they are not a guarantee that time-zone rules will never change.