-
All replies
-
Helpful answers
-
-
Dec 18, 2014 12:45 PM in response to Karena126by Gator5000e,I just entered my bug report. Hope they fix this soon.
-
Dec 18, 2014 1:23 PM in response to James Barberby TinkerTots,I too am experiencing the same issue (new calendar appointments created on my iPhone5 running iOS8.1.2 are GMT not EST!
Very frustrating and reflects Apple's crappy testing before releasing.
-
Dec 18, 2014 4:15 PM in response to JG in SBby WonderMikeBerkeley,THANK YOU SO MUCH JG in SB, for persevering and documenting all of this. Apple owes you bug... BIG time. I just reported the bug to Apple via the link you provided.
Here are my summation points:
- I use an iPhone, iPad & MacBook Pro.
- I only use Gmail calendaring to tie them all together.
- The GMT bug only started today (12/18/14).
- I had been running iOS 8.1.1 but updated to 8.1.2 today but this did not solve the problem.
- If I create the calendar event with Gmail (on my MBP) the GMT reference does not show.
Keeping my eyes peeled in this space for a resolution.
Again, many thanks and happy holidaze!
~Michael
-
-
Dec 18, 2014 4:26 PM in response to WonderMikeBerkeleyby MrRell,The bug did not start today. I have been experiencing it for at least 2 weeks now. Since probably 8.1. I updated to 8.1.1 and 8.1.2 the day they came out. No difference.
-
Dec 18, 2014 6:51 PM in response to MrRellby JG in SB,I think what WonderMikeBerkeley means is that the bug started on his devices today. Which is entirely possible. The bug itself has been around since the very first update to iOS 8.0. It showed up on my iOS devices in September immediately following the first iOS 8.0 update. But for some users it did not show up until recently.
The bug is baked in to iOS 8, but you will only see it if the server on which your calendar is running (i.e. the specific Google Calendar server your account resides on) is in a different time zone than your devices are in.
So if a particular user's Google Calendar account was on a Google server with system time set to the same time as that user's iOS devices, that user would not see this bug even though it was there in the code on his/her devices. When the user's account is moved to a different Google server that is in a different time zone than the user's iOS devices are set to, the bug will show up.
This is why many users of Google Calendar have reported that they were just fine on iOS 8.x until about two weeks ago and then this bug showed up without any settings changing on their devices. The variable that changed is the system time setting on the server that hosts their account(s). This happened either because Google reset the time on the server, or more likely, that these users' accounts were migrated to a different server at Google, set to a different time setting, as part of a load balancing operation within Google's infrastructure.
-
Dec 18, 2014 8:50 PM in response to Kandids by Kelliby 1emike,Just to clarify: this is only an issue with the default setting, right? In other words, I have the same problem as illustrated on the first page of this thread, but if I go into the Event Details, Edit, Starts, Time Zone is set to GMT. I then change it to Chicago (my proxy for Central time, USA) and the GMT line disappears from the appointment in calendar view. (You also have to re-select the time -- otherwise, say, an 11:00am appointment would become a 5:00pm appointment, because 5:00pm GMT, with an 11:00am Chicago location, was changed to 5:00pm Chicago time.) I wanted to mention this because some of the draconian solutions (like deleting appointments) don't really make sense if you can individually edit the appointments as I can. It would be great to fix the default, but it's easy to fix one-by-one, right?
-
Dec 18, 2014 8:53 PM in response to 1emikeby JG in SB,@1emike: the problem is a lot more complicated than that. When you open an appointment to edit it...and all you do is change the time zone....iOS leaves the transposed times in the appointment.
For example, I currently have an appointment in my calenderr that goes from 3pm to 4pm PST tomorrow (12/19). I created it on my iPad, so thanks to iOS 8 and this bug, it has synced to my iPhone and shows at 3pm to 4pm graphically but also says "11pm to 12 AM (GMT)" If I open up this appointment to edit it, the start time actually IS 11:00 PM GMT. If I then click on that to change the time zone to PST....iOS leaves the 11:00 PM start time but does change the time zone to PST. So now, an appointment I set up as 3:00 pm PST is now starting at 11:00 PM PST.
If you want to edit an appointment you have to manually enter in the correct start and end times after you have also changed the time zone. It is like an 8 step process. The fastest way to edit an appointment until Apple gets off the stick and fixes this problem is to drag it to the new time in the graphical view. It will still be at the transposed time, but it will look correct and you don't have to go through the 8 step process.
-
Dec 18, 2014 10:17 PM in response to JG in SBby 1emike,@JG in SB: I think we're saying the same thing -- you need to re-select the start time in your local time (see the parens in my post above) after changing the time zone. My point is that, up until now, I didn't see anything acknowledging that you could simply edit the post -- extra steps though it may be. (Of course, I did not read all posts in all 13 pages.) However, I saw posts that talked about deleting events in your calendar and re-entering them. There would never be a reason to do that, right?
-
Dec 18, 2014 10:39 PM in response to 1emikeby 1emike,Follow-up: In other words, when I first enter the appointment, the time zone says "Chicago," but it changes to GMT (with a Chicago time zone location) after I hit "Done." When I edit the appointment back to Chicago time, it sticks. Thus, the issue is with the default, not with the ability to choose your time zone -- at least for me.
-
Dec 18, 2014 11:03 PM in response to 1emikeby JG in SB,Correct 1emike.... there is absolutely no reason to delete and re-create an event. That's especially pointless because as soon as you do that, the event is just going to sync over to your other iOS devices and it will convert to GMT on those devices....
Also, I am not 100% sure that once you "edit the appointment back to Chicago time it sticks." It for sure sticks on the device you just edited it on, but the synced version on your other iOS devices is going to transpose right back to GMT. I am 99% certain about this and I will test it when I have my iPhone and iPad in the same place. I am also going to check to see whether the GMT transpose occurs if I manually select the time zone when creating an event on an iOS device instead of just letting it default to my current time zone. I'm in PST so I will manually set some up and input Los Angeles on one and then I'll try another set up as a CST appointment in say.....Houston. I am pretty certain both of these will transpose anyway, but worth testing it.
Even if you create an appointment on a non iOS device (like accessing your Gmail Calendar using the web browser on your desktop computer) and it syncs down to all of your iOS devices without transposing to GMT (appointments created by non-iOS devices don;t get transposed to GMT on the iOS devices subscribed to the same calendar), once you edit that very same appointment on any iOS device, it will transpose to GMT on all your other iOS devices.
The reason for this is that the buggy iOS 8.x code causes the time zone shift to occur on the iOS device at the receiving end of the synchronization. The "sender" iOS device puts the bad time zone data into the appointment, but it doesn't get displayed until the "receiver" device syncs it down through your server. If the "source" of an appointment (either from scratch or edited) is an iOS device....it will look just fine on the source device, but all receiver iOS devices will add the GMT thing and actually change the times to GMT.
-
Dec 19, 2014 12:34 AM in response to 1emikeby JG in SB,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.....
-
Dec 19, 2014 12:34 AM in response to JG in SBby Kid Dynamic,JG et al, thanks for this thorough discussion of the issue.
JG you mentioned that you have to use two iDevices to see the issue... but I only have one (iPhone 5, 8.1.2), and I am seeing the issue as well.
Every event I've created since Dec 15th now shows (GMT), and although I used my own time zone when creating it (Pacific), when I go to edit it, it shows GMT as the default time zone.
The calendar at issue is a Google calendar. I only have an iPhone and my Mac, and I use Chrome on my Mac for calendaring so haven't noticed the bug there.
I have submitted a bug / feedback request, and will do so again until this bug is fixed.
And as for the debate about whose fault it is... I don't care whose fault it is. Google and Apple need to get their act together and fix this.
(Oh, also BTW my Facebook calendar that iOS has integrated is also showing GMT. It has been doing that for quite a while now)
-
Dec 19, 2014 12:52 AM in response to Kid Dynamicby JG in SB,Kid Dynamic...I have a theory but my setup is different than yours so maybe you can test this out....
- Create an appointment on your iPhone (call it "iPhone Appointment").
- As soon as you create it and save it on your iPhone, check to see if the "(GMT)" thing is on it.......I suspect it won't be.
- Create a different appointment in Google Calendar directly on the Google server by using the web browser access to your calendar from any non iOS device (call it "Web Appointment"). We want an appointment that is "sterile"......having never existed on an iOS device until it later syncs to your iPhone.
- Check your iPhone to see as soon as the Web Appointment syncs to it and see if the "(GMT)" thing is on it.......I suspect it won't be.
- Wait a few hours and then look at both "iPhone Appointment" and "Web Appointment" on your iPhone again and see if the ("GMT") thing is there....I suspect it WILL BE there on both appointments.
If you could do this test and report back that would be awesome. I may be totally wrong about what shows up but whatever shows up in this structured test can help to further isolate the factor(s) that generate the problem. I have a theory about why you are seeing this on your device even though you are only using that single device. The cause is exactly the same as what I described above....but it may manifest differently due to the manner in which Google Calendar synchronizes data vs. the way Exchange does it. The test above can help to confirm this.....or not. Either is useful info to have.
Thanks in advance.

