Always include UTC
You should always include UTC (note, not GMT but UTC, see the already-mentioned comments; GMT is nowaday only used as British winter time).
If you can, also include one or more local times, but do always include UTC.
Rationale:
If the invitation crosses to some place far away (not uncommon in internet times), people might not know what timezone e.g. “PDT” is. Worse, those time zone identifiers are not unique, and there aren’t really any well-understood unique time identifiers (we have Olson timezones for much of the Unix world, but the Windows world differs).
Most people around the world, however, do know the relation of their local time to UTC. If not, time offset calculators are usually easy to find.
Even if the recipient knows which timezone you reside in, they usually would have to calculate UTC first, then their own localtime. Converting a foreign time zone’s timestamp is more error-prone than your own.
There’s something to be said about converting to the well-understood baseline standard on the sender side, so recipents need to only care about their own location in relation to the standard.
This also avoids problems like the international date line, which people living in other parts of the world (if you’re one of them) may not even know about or consider.
About including local time
If you know a non-negligible subset of your recipients shares one (or a few) common timezones, and if calculation of these offsets is easy enough for you to do it safely, include them as courtesy.
Bonus effects
Recipients on vacation or remoting
If a recipient is not at their home location, they may have a different timezone which you could not know beforehand. See above for relative ease of calculating from UTC, only now, the recipient’s in a timezone neither you nor them know well, so they’ll likely resort to online tools… or ask a local, who, again, might only know their relation to UTC.
DST transitions
If you’re forced to include a fixed UTC time for each meeting incidence, you won’t have problems with recurring meetings when a part of the recipients switch from/to DST but another part doesn’t.
DST transition times differ between the USA and Europe, for example. (I personally always have “fun” with that with Munzee, who only include what I believe is Texas time, although I know by now that the Eventzee weekend activity ends on Sunday 22:00 in my own timezone except for the few weeks of the year where USA and Europe are out of sync, in which… I actually don’t know.)
So you’ll have either a fixed meeting time in UTC (and everyone will have to schedule their own local-time meetings around it when their own DST transition occurs), or you’ll list the UTC time of all recurrences to fix it to one timezone… or you avoid meetings recurring across DST transitions altogether.