The useful question is not simply what each clock displays. You need to compare one shared instant, then express that instant under the rules of each zone.
Start with the same instant
Two local clock readings are comparable only when they represent the same instant. Current comparisons should therefore begin with one server timestamp. A planned comparison begins with a local date and time in a named source zone, which can be resolved to an instant before the destination is calculated. This avoids accidentally comparing unrelated readings.
Compare offsets, not city stereotypes
At a particular instant, every zone has an offset from UTC. Subtracting the source offset from the destination offset gives the clock difference. But the offset belongs to that instant, not permanently to a city. One place may change seasonally while the other does not, so a memorized difference can be right in January and wrong in July.
Check the calendar day too
A clock difference does not tell the whole story near midnight. The destination may already be on the next day or still on the previous one. Keep the local date beside each clock and show the day relation explicitly. For planning a call, meeting, or arrival, that small label prevents more mistakes than an offset number alone.