'GMT Bug' in iOS 8 Calendar Syncing Causing Time Zone Confusion for Users

[Zxxv]

UTC wtf is dat?

Oh yea it's jealously ... GMT the time zone they don't want to use because it's a British invention.

(So the story goes)

(All this drama because)

 

[Morris]

UTC wtf is dat?

Oh yea it's jealously ... GMT the time zone they don't want to use because it's a British invention.

(So the story goes)

(All this drama because)

UTC and GMT are not the same. Although the time difference between both is almost zero (approximately due to leap seconds and earth rotation not being constant), GMT is a time zone while UTC is not (it is an atomic scale).

Whenever you do anything with times or dates in computing you should always use UTC and ISO8601 Years/Months/Weeks/Days internally. Depending on someone's location or time zone you then convert from UTC to what's relevant wherever they are at that particular time.

 

[baryon]

It isn't quite so simple. If someone in another time zone sends you a teleconference request you will want your calendar to know what local time that represents for you, and you will also want it to adjust if you are in yet another time zone when the conference happens.

True, but over the past 6 years I've never had to adjust to a teleconference, and if I do, I just type "What time is it in ......" into Google and it tells me. However, over the past 6 years, every single day I had to confront the fact that the times in my calendar are absolutely meaningless because they depend on which country I happened to be in when I wrote them, and which country I happen to be now, both of which have nothing to do with the time of the event I'm after.

Both uses make sense, so it would make sense for Apple to include a checkmark that says "enable Time Zone support" that would enable/disable this behaviour - oh wait, they did do that! But wait, it doesn't work. If you disable time zone support, then Calendar will automatically change all the times for you whenever you travel. If you enable it, it will automatically change them for you, except you can select which time zone to adjust them to. Which doesn't work if you have ever been to more than one time zone because you have to keep changing the time zone in the top right corner manually...

 

[Zxxv]

UTC and GMT are not the same. Although the time difference between both is almost zero (approximately due to leap seconds and earth rotation not being constant), GMT is a time zone while UTC is not (it is an atomic scale).

Whenever you do anything with times or dates in computing you should always use UTC and ISO8601 Years/Months/Weeks/Days internally. Depending on someone's location or time zone you then convert from UTC to what's relevant wherever they are at that particular time.

Thanks for a great answer

----------

True, but over the past 6 years I've never had to adjust to a teleconference, and if I do, I just type "What time is it in ......" into Google and it tells me. However, over the past 6 years, every single day I had to confront the fact that the times in my calendar are absolutely meaningless because they depend on which country I happened to be in when I wrote them, and which country I happen to be now, both of which have nothing to do with the time of the event I'm after.

Both uses make sense, so it would make sense for Apple to include a checkmark that says "enable Time Zone support" that would enable/disable this behaviour - oh wait, they did do that! But wait, it doesn't work. If you disable time zone support, then Calendar will automatically change all the times for you whenever you travel. If you enable it, it will automatically change them for you, except you can select which time zone to adjust them to. Which doesn't work if you have ever been to more than one time zone because you have to keep changing the time zone in the top right corner manually...

And reading that is why this is such a confusion for a lot of people

 

[IJ Reilly]

UTC and GMT are not the same. Although the time difference between both is almost zero (approximately due to leap seconds and earth rotation not being constant), GMT is a time zone while UTC is not (it is an atomic scale).

Whenever you do anything with times or dates in computing you should always use UTC and ISO8601 Years/Months/Weeks/Days internally. Depending on someone's location or time zone you then convert from UTC to what's relevant wherever they are at that particular time.

UTC is also not adjusted for Summer or Daylight Savings time. It's a constant, which is why it instead of local times or GMT are used for aviation and meteorology.

----------

True, but over the past 6 years I've never had to adjust to a teleconference, and if I do, I just type "What time is it in ......" into Google and it tells me. However, over the past 6 years, every single day I had to confront the fact that the times in my calendar are absolutely meaningless because they depend on which country I happened to be in when I wrote them, and which country I happen to be now, both of which have nothing to do with the time of the event I'm after.

Both uses make sense, so it would make sense for Apple to include a checkmark that says "enable Time Zone support" that would enable/disable this behaviour - oh wait, they did do that! But wait, it doesn't work. If you disable time zone support, then Calendar will automatically change all the times for you whenever you travel. If you enable it, it will automatically change them for you, except you can select which time zone to adjust them to. Which doesn't work if you have ever been to more than one time zone because you have to keep changing the time zone in the top right corner manually...

Your point raises the obvious question of whether anyone has provided a solution to timezones and mobile calendars that actually works in more situations. Seems to me any solution is going make assumptions that aren't always going to be the right ones.

 

[NMBob]

As a programmer, I can tell you that time zones cause some of the biggest headaches across all types of development. It's really not that surprising.

As a programmer for over 30 years, I can tell you that if timezones are giving you trouble you're not doing it right. Now if someone else's server is not doing it right then that's another problem, and that's the part I find funny.

Also, part what bayron's post said -- it's a calendar, not a clock -- but that can also come back to it being someone else's server.

And the part in ovil200's post about Google using UTC for everything. Hint hint.

My guess is that the problem is being caused by marijuana already being legalized on Apple's campus.

 

[CPx]

Lol, ironic since there isn't any sort of issue as what you're describing. Something tells me you don't have a full grasp on the entire issue. It's written plain as day on Google's website. This is only evident on Calendar because of how Calendar handles time zones, but it's certainly not a bug. It's working exactly as Google and Apple intended for their respective services. If any change comes from this, it will be to revise the software to prevent confusion. That's all this is -- confusion. There is no bug, because it clearly states on Google's website this is expected. Quote from the Google link I posted, since it seems no one is actually reading it:

"Whenever you create an event, Calendar converts it from your time zone to UTC time, using currently known conversion rules. By using one universal time for all events, Calendar can keep all of your guests’ calendars consistent regardless of which time zones they're in. When we display the event on your calendar, it is converted from UTC to appear in your own time zone.

If you have a recurring meeting that spans across different time zones, then its time always remains constant for the organizer, and will shift for guests whenever their time difference with the organizer changes. That’s why if you’re in London and attending a weekly meeting that was created by your New York colleagues at 10am NY time, it will always be at 10am for NY, almost always at 3pm for you, but at 2pm during that particular week in early November.

However, this process doesn't always work in cases where a country decides to change when they switch to DST or even their overall time zone. If you had created an event before we knew about the change, Calendar converted your time zone into UTC, using the information available at the time of creation. Once the time zone change is known, Calendar will use the new rule to display events in your time zone, and it might cause events to shift in your calendar.

Let’s look once more into the Russian example. If you in March 2011 created an event for Nov 2011 at 17:00 MSK, then according to rules we knew in March, we would store it as 14:00 UTC. After the switch happened in Russia, Google Calendar takes the new rule and converts this event to 18:00 MSK. Luckily, all participants and rooms that you booked are still available for this meeting."

Edit for clarity, since I'm sure someone will reply with an angry counterpost calling me an ignorant fanboy; be sure to check out the screenshot. It shows the events in the appropriate time slot. The only part people are freaking out over is that it simply shows the GMT time zone. I'm not sure how this is confusing for people, but it's apparently SO confusing that people think it's a bug. If there is a bug that is REPLACING the time zone, then it's not the one described in this post by Macrumors. This post by Macrumors describes something that is expected behavior. When I reported this to Apple, the Apple engineers stated that it was expected. Google's own website states that it is expected. There is no counter-argument unless you're describing an unrelated issue than the one described in Macrumors' post. Simply because some folks in customer support said that it's an issue does not mean it actually is. I'm inclined to believe Apple's engineers and Google's webpage over a customer support employee. There is no issue here, at all.

Watch the video at this time point: https://www.youtube.com/watch?v=cgP1zyi_iV8#t=137

Watch till the 4 minute mark. It's more than just showing a bit of extra information. In no way shape or form is this intentional behavior.

 

[TimelessOne]

Lol, ironic since there isn't any sort of issue as what you're describing. Something tells me you don't have a full grasp on the entire issue. It's written plain as day on Google's website. This is only evident on Calendar because of how Calendar handles time zones, but it's certainly not a bug. It's working exactly as Google and Apple intended for their respective services. If any change comes from this, it will be to revise the software to prevent confusion. That's all this is -- confusion. There is no bug, because it clearly states on Google's website this is expected. Quote from the Google link I posted, since it seems no one is actually reading it:

"Whenever you create an event, Calendar converts it from your time zone to UTC time, using currently known conversion rules. By using one universal time for all events, Calendar can keep all of your guests’ calendars consistent regardless of which time zones they're in. When we display the event on your calendar, it is converted from UTC to appear in your own time zone.

If you have a recurring meeting that spans across different time zones, then its time always remains constant for the organizer, and will shift for guests whenever their time difference with the organizer changes. That’s why if you’re in London and attending a weekly meeting that was created by your New York colleagues at 10am NY time, it will always be at 10am for NY, almost always at 3pm for you, but at 2pm during that particular week in early November.

However, this process doesn't always work in cases where a country decides to change when they switch to DST or even their overall time zone. If you had created an event before we knew about the change, Calendar converted your time zone into UTC, using the information available at the time of creation. Once the time zone change is known, Calendar will use the new rule to display events in your time zone, and it might cause events to shift in your calendar.

Let’s look once more into the Russian example. If you in March 2011 created an event for Nov 2011 at 17:00 MSK, then according to rules we knew in March, we would store it as 14:00 UTC. After the switch happened in Russia, Google Calendar takes the new rule and converts this event to 18:00 MSK. Luckily, all participants and rooms that you booked are still available for this meeting."

Edit for clarity, since I'm sure someone will reply with an angry counterpost calling me an ignorant fanboy; be sure to check out the screenshot. It shows the events in the appropriate time slot. The only part people are freaking out over is that it simply shows the GMT time zone. I'm not sure how this is confusing for people, but it's apparently SO confusing that people think it's a bug. If there is a bug that is REPLACING the time zone, then it's not the one described in this post by Macrumors. This post by Macrumors describes something that is expected behavior. When I reported this to Apple, the Apple engineers stated that it was expected. Google's own website states that it is expected. There is no counter-argument unless you're describing an unrelated issue than the one described in Macrumors' post. Simply because some folks in customer support said that it's an issue does not mean it actually is. I'm inclined to believe Apple's engineers and Google's webpage over a customer support employee. There is no issue here, at all.

I think you do not understand what a bug is. Even though it is wia it appears to be a bug and it is acting like a bugand new. There for it is a bug. It is apple that put the bug in and bug needs to be fixed by them.

 

[JG in SB]

Uuuum, it's a BUG

Lol, ironic since there isn't any sort of issue as what you're describing. Something tells me you don't have a full grasp on the entire issue. It's written plain as day on Google's website......I'm inclined to believe Apple's engineers and Google's webpage over a customer support employee. There is no issue here, at all.

Apple's engineers HAVE confirmed this is a BUG in iOS 8. If you are inclined to believe them over other sources, then why do you not believe them when they confirm this is a bug? There are copies of their E-mails in the Apple Support Communities thread about this. The AppRiver blog article from early November about this issue also documents Apple Engineering's confirmation that they know this is a bug in iOS 8.

Also, there's the not-so-insignificant fact that this BUG affects people who don't use Google products for anything....me for example. I use Exchange and I have this very same BUG. So your paragraphs expounding on what the Google website says, besides being totally unrelated to this bug, are certainly irrelevant in the case of the many users who experience this BUG in technical environments where no Google services are used.

If you do a little research, instead of being so sure you are right about this and everyone else has no idea what they are talking about....you might conclude that you are the one who "doesn't have a full grasp on the entire issue."

 

[JG in SB]

Edit for clarity, since I'm sure someone will reply with an angry counterpost calling me an ignorant fanboy; be sure to check out the screenshot. It shows the events in the appropriate time slot. The only part people are freaking out over is that it simply shows the GMT time zone.

Wrong again. It doesn't just "simply show the GMT time zone." It CONVERTS the appointment to GMT time zone. Watch the video and you can see this with your own eyes, along with why this is a major problem.

I'm not angry and I don't think you are "an ignorant fanboy." I think you are someone who does not fully understand what you are talking about, but who is still outspoken about the issue, and stubbornly welded to your initial belief despite being provided with multiple facts that indicate your belief is totally incorrect. Pretty common on the internet these days....

 

[CFreymarc]

How long has time been around again? Time bugs just make me laugh. It's funny how something so old is still gotten wrong by so many [programmers].

Measured time has been around since ancient times but not til the 19th centric has it needed to be synchronized over long distances for daily routines.

Several 19th century military conflicts were lost due to lack of time synchronization. This is why GMT and zero latitude crosses at the British Isles at the height of their world empire.

As a developer, there are established time zone and GMT software objects that sync with atomic clocks on the net. Most of these bugs come from improper UI implementations.

 

[doerrmann]

Did you review the Google link? It states that Google deliberately does this.

Obviously you're not having the problem... It's a bug because it's unexpected behavior that occurs in iOS 8 and most Google and some non-Google Exchange servers. It doesn't occur in iOS 7, it doesn't occur in my work Exchange account, and it doesn't occur for everyone.

The Google article explains the issue quite well, but it's still not the intended behavior. When an appointment is created in iOS, it loses the initial time zone it was created it. So I create an appointment, and it gets converted to the correct time, but in GMT. When I create an appointment in the Central time zone in Google calendar online, it remains in the Central time zone, and other time zones see it at the correct time in their local time zone.

Something is lost between iOS 8 (not iOS 7 or earlier) and some (but not all) Exchange servers, most notably Google calendar. It cannot be repeated by creating the same appointment the same way using Google calendar online.

 

[PJL500]

Lol, ironic since there isn't any sort of issue as what you're describing. Something tells me you don't have a full grasp on the entire issue. It's written plain as day on Google's website. This is only evident on Calendar because of how Calendar handles time zones, but it's certainly not a bug. It's working exactly as Google and Apple intended for their respective services. If any change comes from this, it will be to revise the software to prevent confusion. That's all this is -- confusion. There is no bug, because it clearly states on Google's website this is expected. Quote from the Google link I posted, since it seems no one is actually reading it:

"Whenever you create an event, Calendar converts it from your time zone to UTC time, using currently known conversion rules. By using one universal time for all events, Calendar can keep all of your guests’ calendars consistent regardless of which time zones they're in. When we display the event on your calendar, it is converted from UTC to appear in your own time zone.

If you have a recurring meeting that spans across different time zones, then its time always remains constant for the organizer, and will shift for guests whenever their time difference with the organizer changes. That’s why if you’re in London and attending a weekly meeting that was created by your New York colleagues at 10am NY time, it will always be at 10am for NY, almost always at 3pm for you, but at 2pm during that particular week in early November.

However, this process doesn't always work in cases where a country decides to change when they switch to DST or even their overall time zone. If you had created an event before we knew about the change, Calendar converted your time zone into UTC, using the information available at the time of creation. Once the time zone change is known, Calendar will use the new rule to display events in your time zone, and it might cause events to shift in your calendar.

Let’s look once more into the Russian example. If you in March 2011 created an event for Nov 2011 at 17:00 MSK, then according to rules we knew in March, we would store it as 14:00 UTC. After the switch happened in Russia, Google Calendar takes the new rule and converts this event to 18:00 MSK. Luckily, all participants and rooms that you booked are still available for this meeting."

Edit for clarity, since I'm sure someone will reply with an angry counterpost calling me an ignorant fanboy; be sure to check out the screenshot. It shows the events in the appropriate time slot. The only part people are freaking out over is that it simply shows the GMT time zone. I'm not sure how this is confusing for people, but it's apparently SO confusing that people think it's a bug. If there is a bug that is REPLACING the time zone, then it's not the one described in this post by Macrumors. This post by Macrumors describes something that is expected behavior. When I reported this to Apple, the Apple engineers stated that it was expected. Google's own website states that it is expected. There is no counter-argument unless you're describing an unrelated issue than the one described in Macrumors' post. Simply because some folks in customer support said that it's an issue does not mean it actually is. I'm inclined to believe Apple's engineers and Google's webpage over a customer support employee. There is no issue here, at all.

Event scheduled for 3.00 PM PT later shows up as 11.00 PM GMT. Capisce?

 

[davidsdiego]

I'm glad I'm not the only one; I was going crazy!

 

[technosix]

This has been happening to me since about November 2014 and is frustrating to say the least. It is surprising that a company such as Mac/Apple took so long to acknowledge this bug and has not fixed it at this late date.

I really hope they fix this soon, I rely on my calendar and the accuracy of it in my business, my own business.

I too find this frustrating and look forward to Apple fixing it.

 

[Jibbajabba]

Well it's iOS 8 so even the simplest of things are riddled with bugs.

You are just timezoning it wrong ;-)

 

[NAYo2002]

potential fix

I got mine fixed by going to Google Calendar (non-mobile version.) It asked me at the top of the page to update to the new version. When I clicked it, it refreshed and asked me to accepted a timezone (EST in my case.) After I did those two steps, I no longer have this issue. I hope this works for everyone.

 

[IJ Reilly]

Measured time has been around since ancient times but not til the 19th centric has it needed to be synchronized over long distances for daily routines.

Several 19th century military conflicts were lost due to lack of time synchronization. This is why GMT and zero latitude crosses at the British Isles at the height of their world empire.

As a developer, there are established time zone and GMT software objects that sync with atomic clocks on the net. Most of these bugs come from improper UI implementations.

FWIW the railroads were the first to see the need for standardized time. This was a kind of revolution when it happened as previously every city, town and village could be on its own time and it hardly mattered. The revolution we are experiencing now is portable devices that reset their clocks automatically based on current location. I don't see how software can always know what a user intended when they entered an appointment into their calendar in one time zone and then travelled to another.

In any case I don't think nanoseconds or even minutes are the issue here, so it isn't a question of split-second accuracy relying on atomic clocks.

 

[AlecZ]

Yet another stupid little iOS 8 bug where a really basic feature won't work right. I find a new one every day. My iPhone 6 would be running iOS 7 if I could make it do that because it seems like "It just works" died a year ago at Apple.

 

[Hayakuro]

I only use iCloud

Huh, that's interesting. Maybe you can set it to use the lighter colors via the Calendar app on iCloud.com? That's how mine came set up from the beginning, and my Google calendars always use the darker shades.

 

[CFreymarc]

FWIW the railroads were the first to see the need for standardized time. This was a kind of revolution when it happened as previously every city, town and village could be on its own time and it hardly mattered.

The railroads was the first civilian implementation of synchronized time zones. Before that, during the early Victorian period, the British Empire used synchronized time zones as a military tactical secret to coordinate overseas invasions. It was instrumental of the invasion of India and other locations. Decades later, it went public.

The revolution we are experiencing now is portable devices that reset their clocks automatically based on current location. I don't see how software can always know what a user intended when they entered an appointment into their calendar in one time zone and then traveled to another.

In any case I don't think nanoseconds or even minutes are the issue here, so it isn't a question of split-second accuracy relying on atomic clocks.

You took it out of context. Mentioned atomic clocks over the source of the data and not the accuracy. Again, this bug is a big UI bug from a junior Apple employee at the keyboard and a lack of good source code reviews. When Steve was around, the team who let this bug get out would be ex-Apples employee consulting to top 100 app developers by now.

 

[JG in SB]

The programmers failed, but the REAL failure is how Apple has handled this....

Again, this bug is a big UI bug from a junior Apple employee at the keyboard and a lack of good source code reviews. When Steve was around, the team who let this bug get out would be ex-Apples employee consulting to top 100 app developers by now.

^^That. They are in so much of a hurry now to get new software releases out that it appears they are not doing ANY quality control. This is a HUGE and very noticeable bug. How did it get missed by beta testers or even Apple employees? Seems like they just tested it with iCloud and said "great, it works, release it!!"

IMHO the team who let this get out into the wild did not do their jobs. But the ultimate failure here is how Apple has handled things once the bug was reported to them. Instead of saying: "ok, something is up here, let's figure out if it is a problem with iOS and if it is, let's get it fixed ASAp and let people know we are working on it" they said "we'll blame the user and deny that this could even possibly be generated by iOS....if enough people start to complain about it maybe we'll look into it but we'll never admit we did anything wrong and we definitely won't let anyone know what's going on."

Four months after this was reported to Apple, and even following widespread news reports of the GMT bug last Friday (1/23/15) Apple tech support and retail employees are still telling customers that they have "never heard of this before." What a spectacular failure of internal communication and customer service.

 

[Zxxv]

Huh, that's interesting. Maybe you can set it to use the lighter colors via the Calendar app on iCloud.com? That's how mine came set up from the beginning, and my Google calendars always use the darker shades.

Just checked. Think it's because I haven't entered anything for those coloured calendars. Thanks for the help.

 

[TimelessOne]

As a programmer for over 30 years, I can tell you that if timezones are giving you trouble you're not doing it right. Now if someone else's server is not doing it right then that's another problem, and that's the part I find funny.

Also, part what bayron's post said -- it's a calendar, not a clock -- but that can also come back to it being someone else's server.

And the part in ovil200's post about Google using UTC for everything. Hint hint.

My guess is that the problem is being caused by marijuana already being legalized on Apple's campus.

But like you said timezones become a huge head ache when you start going between external and internal as one of the external ones screw things up. Big-time when one of the external devices you have to communicate with is legacy with some just plan bad time code in it.

Now timezones can be a head ache when they are user defined (I choose this date and time) and you have to know is that one I want to say always that or shift with time zones. I find the bug I have seen on time zones is just the minor ones like forgetting to hand the time is returned locally and then you the developer needs to convert it to utc to store. I want the display date to always be 3/3/2015 so that should be stored as 3/3/2015 midnight utc.

 

[dBeats]

This is nothing compared to the bug (it's actually a feature but I refuse to call it that) in OS X's calendar which changes the TIME of ALL events (in the past, present and future) if you simply move your computer into a different country. I mean holy hell, you just VISIT Paris and suddenly your flight is 5 hours earlier than it should be just because you didn't specify that at the time when you will be looking at the screen, you will be in the GMT+01 time zone.

Try having a meeting with people in different time zones and you'll see that your opinion isn't valid for all use cases. In fact, when you put your flight out of Paris in your calendar in your own timezone, you in fact put the wrong time. All you have to do is when you add the calendar event say

Flight #xxx from CDG to YYZ at 11:00am CET

Problem solved...