OK. Tested and the results are exactly as predicted. Here is a screenshot of two fake appointments I set up for tomorrow (12/20) on my iPhone (we'll call it the "Source iOS Device"):
I "hard set" the time zone for each appointment when I created it .... instead of just selecting the start and end times, I actually opened each up, selected a city in the desired time zone, THEN selected the times, then saved it. The 1st appointment above is in PST and I hard set the time zone to Los Angeles. The second is in CST and I hard set the time zone to Houston. I have "Time Zone Override" set to "Off" as well (turning it on or off doesn't do anything in any case). You can see in the case of the 1st appointment in PST that it is not showing the "(GMT)" thing on the Source iOS Device, and that it is correctly showing a second time in CST for the second appointment that I intentionally DID set to CST.
So here's what these same two appointments look like on my iPad (we'll call it the "Receiver iOS Device") once they sync over to it through my server:
You can see that both still display graphically at the correct PST times in my calendar, but that both appointments have been transposed to GMT. In the case of the hard set PST appointment, iOS has transposed it to GMT (adding 8 hours to the 1pm PST start time), and in the case of the hard set CST appointment, iOS has also transposed that one to GMT (adding 6 hours to the 5pm CST start time).
This experiment confirms that this bug is unrelated to whether or not you are using the default time zone when you set up appointments. This also confirms what AppRiver presents in this article: http://blog.appriver.com/2014/12/ios-8-calendar-events-display-dual-time-zones/ What appears to be happening is that when any event created on the Source iOS Device passes through the subscribed calendar server (Exchange, Google Calendar, etc.) it is: 1) querying the server to find out what the system time on the server is set to; and 2) adding the server system time data to the data embedded in the appointment. Then when the Receiver iOS Device receives the appointment, with this embedded data in it, it reads the server system time data and transposes the appointment to the system time that the server is set to. Not the time zone the user has set in their account...I mean the actual system clock time set on the specific server hardware that the user's calendar is hosted on. My server's system time is set to GMT. If your server's system time is set to EST this exact same thing will happen but your appointments will transpose to "(EST)" instead of "(GMT)".
Just for fun, I edited the PST appointment on the iPad...hard setting the time zone back to PST and manually resetting both the start and end times to 1:00 pm and 2:00 pm respectively. This causes the "(GMT)" time to disappear from the appointment on my iPad. But, as expected...when the newly updated appointment syncs back to my iPhone, the "(GMT)" is displayed and it is now transposed to GMT on the iPhone. So this confirms that in fact it does not "stick" when you go in and manually change it to remove the "(GMT)" notation on your iOS device....it fixes it on THAT device but screws it up on any other iOS devices that it syncs over to. Why does this happen? As the appointment you just "fixed" syncs back through your server to your other devices, it does the exact same thing that happened the first time: it somehow reads the system time off your server, embeds that in the appointment, and then the receiving iOS device converts the appointment to the server set time zone. You are caught in a never-ending, agonizingly frustrating, totally unwinnable game of data whack-a-mole!!!
I have to say again.....how is it possible that Apple did not identify this in beta testing??? You would think that the publisher of probably the most used mobile operating system of the planet might have checked to make sure the code they just updated worked correctly with probably the two most-used personal information data hosting services on the planet: Exchange and Google. I think the only way this could have happened is that Apple literally did not quality test this at all.....