Date, time, and schedules
What time is an overseas meeting in my time zone?
Tools to use
A meeting shifts by an hour after reusing last month's offset. Time differences depend on the date as well as the cities. Ask how each region displays a particular instant on the event date, rather than memorizing one permanent Tokyo/New York difference.
The tool can display one known instant in several zones, or resolve a local wall-clock reading into an instant. The first has a definite result; the second can have zero or two answers around offset transitions. Choose the mode from the meaning of your input.
Compare Tokyo 21:00 in winter and summer
2024-01-15T12:00:00Z
2024-07-15T12:00:00ZCompare Asia/Tokyo and America/New_York. January gives Tokyo 21:00 and New York 07:00; July gives Tokyo 21:00 and New York 08:00. New York changes from -05:00 to -04:00 while Tokyo's clock reading stays the same. Check the event date, not today's offset.
These fixed historical dates make a reproducible experiment, not a guarantee of future policy. Zone rules change, and distant schedules depend on data updates in devices and booking systems. Recheck participants' calendar displays near important events.
-05:00 and America/New_York carry different information
-05:00 states an offset for a moment; America/New_York identifies rules that vary by date. An offset timestamp can communicate one instant, while '09:00 in this region every month' needs the region's rules. A fixed offset is not a year-round substitute for a zone.
Abbreviations alone may not identify a region uniquely. Share the IANA zone, event date, and local time, optionally with UTC. Naming the clock behind '09:00' reduces assumptions more effectively than sending the time alone.
A place where 02:30 on March 10, 2024 did not exist
2024-03-10T02:30:00New York advanced its clock that day, so 02:30 did not exist. The tool reports an error rather than assuming 03:30 was intended. A booking service must request another time or explicitly define an adjustment policy.
The same clock text can be valid in another region. Format-only validation cannot catch the issue: validity depends on the date and zone together. A syntactically valid local time does not guarantee one corresponding instant.
01:30 on November 3, 2024 occurred twice
2024-11-03T01:30:00earlier: 2024-11-03T05:30:00Z / -04:00
later: 2024-11-03T06:30:00Z / -05:00When the clock moves back, the same 01:30 corresponds to two instants an hour apart. The default reject-ambiguity setting lists candidates without choosing one. Earlier/later selection is available, but that choice belongs to the user or business rule. Keeping the offset in logs and bookings distinguishes the two occurrences.
Every day at 09:00 is not every 24 hours
For recurring events, decide whether local clock time or elapsed spacing is fixed. Across offset changes, daily 09:00 events may not be 24 hours apart. Converting one instant does not create or register a recurring schedule. Use Cron candidate inspection or date addition to examine the relevant rules separately.
A destination may be on the previous or next date. Carry the date and weekday, not just the clock digits. Tokyo Monday morning can still be Sunday elsewhere; availability is separate from correct arithmetic. The tool does not know participants' holidays or working hours.
Verify agreement by returning to UTC
Check that each shared local representation resolves back to the same UTC instant. Convert both start and end, especially for events crossing a date boundary. A dated mapping is more reliable than a note containing only an offset difference.
Test winter, summer, a skipped time, a repeated time, and a date boundary. One ordinary date misses transition behavior. This tool does not submit bookings or jobs, so verify that the destination uses the same zone and ambiguity policy when applying your findings.
Sharing only the clock time can lose a date
Tokyo at 09:00 on January 2, 2024 is 00:00 UTC and 19:00 on January 1 in New York. Sending only 'Tuesday at nine' loses both date and weekday context. Convert one complete source datetime and read the destination date as well as its clock. Near-midnight meetings especially need explicit dates; the other participant may be on the previous day with different working-day assumptions.
A one-off meeting can share one UTC instant. A recurring meeting additionally needs an anchor: Tokyo at 21:00 or a fixed New York morning time. The choice changes schedules after DST transitions. Do not treat one conversion as a year-round offset table. Record the IANA zone and actual dates; future conversions depend on the timezone data available in the execution environment.
Share both complete labels, such as 2024-01-02 09:00 Asia/Tokyo and 2024-01-01 19:00 America/New_York. The tool sends no invitation, so verify the calendar entry separately. Agreeing on one instant also does not make it convenient for everyone. Use conversion to settle time equivalence, then negotiate suitability.