This is why I prefer, and try to use, "<time> <fine-location> time". Like: "Friday 6:30PM Vancouver time" and a world-clock to keep track of when that is. The website time.is is very useful for this.

This takes a bit more effort, but it is less ambiguous and saves you from having to deal with the insanity that is time. DST switching will still cause issues but, as long as you're not the one cursed to implement that software, it should be fine with advance warning.

I'm well aware. See the footnote.

I know it works both ways, too, but probably would be better for the DST observing zone to deal with the effects of DST, instead of foisting such side effects onto our international friends.

In the OP's example, 2023-11-05 01:30:00 America/New_York, 1:30AM occurs twice as at 2:00AM the clock rolls back to 1:00AM. Normally this is resolved by including a disambiguating timezone, EDT (first 1:30AM) or EST (second 1:30AM). But if there's no timezone indication to accompany a geographical location, there's no way to disambiguate the time.

If there's no flag indicating DST. America/New_York is the timezone designation.

Part of what makes TZ discussions incredibly difficult is that people play fast and loose with the terminology.

I think the person you're responding to is simply saying that if you made the meeting in a non-DST observing zone, the meeting time would still wobble in a DST-observing zone. (I'm not sure why they're noting it, because my comment also clearly spells that out, too, albeit in reverse. But yes, it works both ways.)

Right, to pick an actual time stamp for a particular local time in a particular location, you need to first choose at what time stamp to resolve the time offset for the location. Then in that time offset you can unambiguously map the localtime to a unique time stamp.