Time zone conversion looks like subtraction and is not. Three separate things get in the way, and each of them is enough on its own to produce a confidently wrong answer.
The abbreviations do not identify anything
IST is India Standard Time at UTC+5:30. It is also Irish Standard Time at UTC+1, and Israel Standard Time at UTC+2. Three zones, one abbreviation, four and a half hours between the extremes.
CST is US Central, China Standard Time and Cuba Standard Time. BST is British Summer Time and Bangladesh Standard Time. AMT has meant Amazon, Armenia and Amsterdam.
None of these abbreviations is defined by any standard. They are conventions, they collide, and a calculation based on one is a calculation based on a guess about which country the other person meant.
Half the year, EST is not EST
EST is Eastern Standard Time, UTC−5, which the American east coast uses in winter. From March to November it is on EDT, UTC−4.
So "9am EST" in July is, strictly, an hour earlier than the person meant — they are on EDT and using EST loosely, as almost everyone does. The convention is to interpret it as "east coast time" and hope, which works until someone takes it literally.
The same holds for PST, CST and every other pair. Writing ET, PT or CT instead — without the S or D — is at least honest about meaning "whatever that coast is on today".
The offsets are not all whole hours
India is UTC+5:30. Nepal is UTC+5:45, chosen deliberately to differ from India. Parts of Australia sit at UTC+9:30, Iran at UTC+3:30, and the Chatham Islands at UTC+12:45.
Any mental arithmetic that assumes whole hours is thirty or forty-five minutes wrong for a substantial share of the world, including the second most populous country in it.
The clocks change on different dates
The gap between two cities is not constant. Europe and the United States both observe daylight saving and switch on different dates, so for a couple of weeks each spring and autumn the usual difference between London and New York is simply not the usual difference.
The southern hemisphere shifts the other way, so the gap between London and Sydney swings by two hours across the year. And most of Asia and Africa does not observe daylight saving at all, so their gap to Europe changes twice a year without anything happening locally.
This is why a recurring meeting drifts. Nobody moved it; one end moved.
What to use instead
The reliable identifier is the IANA zone name — America/New_York, Asia/Kolkata, Europe/London. It names a place rather than an offset, so it carries that place's entire history and future of rule changes with it.
That distinction matters more than it sounds. An offset is only correct for a moment; a zone is correct for all of them. Storing "UTC+1" against a future appointment in London will be wrong after the clocks change, while storing Europe/London will not.
The database behind those names is updated several times a year, because governments keep changing the rules — often with a few weeks' notice.
Scheduling across zones
Fix the moment, not the wall-clock time. A calendar invitation carries an instant and renders it in each person's own zone, which is the entire point of using one instead of writing a time in an email.
When you must write it down, write the UTC time and let people convert: 14:00 UTC is unambiguous where 3pm my time is not. In chat platforms that support it, a Unix timestamp renders in each reader's own zone automatically and removes the problem entirely.
And when a meeting spans a clock change — the fortnight where one side has shifted and the other has not — confirm rather than assume. That fortnight is where nearly all of these mistakes actually happen.
The short version
Abbreviations are ambiguous; use a converter that names the place. Do not assume whole hours. Do not assume the gap between two cities is the same all year. And write UTC when it has to be written down.