Why can't I always add a fixed number of hours?

Daylight-saving rules depend on the country and date. The difference between two cities can change during the year.

Can I use abbreviations such as CST, IST or BST?

Choose a city or IANA zone instead. Those abbreviations can refer to different regions, so dateify rejects them as ambiguous.

What happens to local time during a clock change?

Some local times do not exist during a spring gap, while an hour occurs twice during an autumn fold. dateify rejects a gap and lets you choose the earlier or later occurrence in a fold.

Does a Unix timestamp store a time zone?

No. A timestamp identifies an instant but does not retain the source city or time zone. Store the zone separately when it matters.

How to convert time between time zones without DST mistakes

The invitation says, “November 1, 2026 at 1:30 AM New York time.” Adding a fixed number of hours is unsafe here: clocks move back on that date, so 1:30 AM occurs twice—first at UTC−04:00, then at UTC−05:00. On an ordinary date, selecting the cities is enough. Near a daylight-saving transition, you also need to identify which occurrence of the local time you mean.

Open the time-zone converter, set the source date, time and city, then add the target zones. It compares the same instant across 2–5 time zones and shows the local date, local time and UTC offset for each one.

A reliable conversion workflow

Confirm the city or IANA zone in which the source time was stated.
Enter the exact local date and wall-clock time from the invitation.
Add participant cities instead of applying fixed adjustments such as “plus three hours.”
Check the resulting date: another zone may already be on the previous or next day.
If the converter reports a clock transition, resolve it instead of ignoring the warning.
Share the result with zone names, for example: 2026-07-23 09:00 Europe/Moscow (UTC+03:00) / 2026-07-23 08:00 Europe/Paris (UTC+02:00).

That format is more useful than “nine Moscow time.” It preserves enough context for another person to verify both the date and the seasonal offset.

Prefer a city to an abbreviation

UTC+3 is a fixed offset. Europe/Moscow is a zone with a history of rules. They may produce the same result for a current date, but they are not the same piece of information. A city-based IANA zone applies the rules that were in effect on the selected date, including daylight saving where applicable.

Abbreviations are riskier. CST, IST, AST and BST can refer to different regions and do not identify one zone. Dateify does not guess their meaning. Choose a city or a full identifier such as America/New_York, Asia/Kolkata or Europe/London.

Offsets are not always whole hours either. Some zones use +05:30 or +05:45. Manual “hour difference” arithmetic can silently lose those 30 or 45 minutes; a row that includes the UTC offset makes them visible.

Spring gaps and autumn folds

A spring clock change creates a gap. If clocks jump from 1:59 AM to 3:00 AM, 2:30 AM never occurs on that date. Dateify reports that input as invalid instead of silently moving it to a later valid time. For a meeting, the right response is to choose a real time and send an updated invitation.

An autumn change creates a fold: the same wall-clock hour occurs twice with different UTC offsets. The converter exposes both valid occurrences and asks for an explicit earlier or later choice. Without that choice, “1:30 AM” does not identify a single instant.

Situation	What to record
Ordinary date	Date, time and IANA zone
Spring gap	A local time that actually exists
Autumn fold	Earlier or later occurrence
Several offices	Each city's result and any date change
Recurring meeting	Dates before and after seasonal transitions

Why a timestamp cannot resolve the original ambiguity

A Unix timestamp already identifies one instant, so it converts cleanly into different local displays. It does not store the name of the source zone, though. If all you have is 1:30 AM in a city during an autumn fold, you must choose one of the two occurrences before a unique timestamp can exist.

When the input is a number from an API or log, first check whether it is in seconds or milliseconds. When the input is a local date, time and city, use the zone converter instead. The two workflows answer different questions.

Before sending the invitation

Include a city or IANA zone, not an ambiguous abbreviation.
Check whether the calendar date changes for another participant.
Record the chosen occurrence during an autumn fold.
For a recurring series, inspect multiple dates because countries do not switch seasonal time in sync.
Put critical meetings into a calendar invitation that stores a precise instant.

The converter runs locally in the browser. Its share link stores the date, time, zones and fold choice in the fragment after #; that fragment is not part of the HTTP request and does not change the page's canonical URL. Time-zone rules can still change through legislation, and the browser supplies the zone database. For a far-future event after a newly announced rule change, verify the result again closer to the date.