Why does the date matter?

Because a time zone is not an offset. New York is five hours behind London in January and four hours behind for a few weeks in spring, because the two change on different dates. Converting with a fixed number is right for about half the year, and this is the single commonest way a scheduled meeting goes wrong.

Where does the daylight saving data come from?

From your browser. Every browser and every version of Node ships the IANA time zone database as part of Intl, which is why this needs no server and no live feed: the rules for every zone are already on your machine, and they are the same rules everything else uses.

Why the warning about clocks changing?

Because a meeting agreed today for a date the other side of a transition happens an hour off what everybody wrote down. The tool checks whether either zone changes offset within a fortnight either side of your date and says so, which is exactly when to double check with the other person.

Time Zone Converter

A time, somewhere else.

Runs in your browserNothing you enter is uploaded, and it keeps working with the network off.

Date

Year first. Daylight saving depends on it.

Time

24 hour clock.

From

A time, somewhere else.

How to use it

Give the date. It matters: the offset changes with the season.
Pick the two zones. By name, not by offset.
Read the warning. It says if the clocks change near then.

When you would use this

A time zone is not an offset, and almost every mistake in this area comes from treating it as one. UTC+1 is a fact about a single moment. Europe/London is a rule that produces UTC+0 for half the year and UTC+1 for the other half, and the dates it switches are not the same dates New York switches. For a few weeks each spring and autumn the gap between London and New York is four hours rather than the usual five, which is why a recurring call agreed in February is an hour wrong in April. So this asks for a date and uses it. The daylight saving rules come from the IANA database, which your browser already ships as part of Intl, so there is no server involved and no live feed to go stale: the same rules your operating system uses. The answer says which offsets actually applied on that date, whether the date itself moves, and how far apart the zones were at that moment. Half hour and quarter hour zones are handled properly, so Kolkata and Kathmandu come out right rather than rounded to the nearest hour. The row worth reading is the warning. If either zone changes offset within a fortnight either side of your date, it says so, because that is precisely the window where a time agreed now will be wrong later and where it is worth confirming with the other person rather than assuming. The southern hemisphere changes in the opposite months, so the gap between Sydney and London moves twice a year and is different again for a few weeks in between.

Questions

Why does the date matter?: Because a time zone is not an offset. New York is five hours behind London in January and four hours behind for a few weeks in spring, because the two change on different dates. Converting with a fixed number is right for about half the year, and this is the single commonest way a scheduled meeting goes wrong.
Where does the daylight saving data come from?: From your browser. Every browser and every version of Node ships the IANA time zone database as part of Intl, which is why this needs no server and no live feed: the rules for every zone are already on your machine, and they are the same rules everything else uses.
Why the warning about clocks changing?: Because a meeting agreed today for a date the other side of a transition happens an hour off what everybody wrote down. The tool checks whether either zone changes offset within a fortnight either side of your date and says so, which is exactly when to double check with the other person.