Different Time Zone issue

I schedule the buildings for our Stake and I travel a good amount for work. This past week, I was in Kansas City (I live in Salt Lake) and had a few people call with some events that needed to be added to the calendar. I did them then when I got home yesterday, I realized that all of them moved up one hour.

For example, I scheduled an event from 5PM-7PM but the calendar not showed it from 4PM-6PM. I was able to change it easily enough but, I believe, it took the time/time zone for where I was at the time (Central Time) and adjusted it to Mountain Time. Maybe when the Locations are created, they should have a time zone and it shouldn't matter where the person is that is creating the event, the time scheduled should match the time zone where the event is to take place.

If it matters, I was using my iPad and a browser to create the event.

This has been discussed previously; see, for example, this post and a few that follow it. I think if you read the explanations in that thread, you'll see that it's working properly (and, indeed, the only way that it reasonably can work) as it adjusts the times for events to correspond to the time zone of the device you are using to view the calendar.

aebrown wrote:I think if you read the explanations in that thread, you'll see that it's working properly (and, indeed, the only way that it reasonably can work)

I read the other post and I guess I am going to have to respectfully disagree about it being the only way it can reasonably work. Here is how I believe it should work:
* Each Location is assigned to a time zone (the time zone of the physical building)
* When a person schedules an event, they are choosing the time that they want the event in the location where the building is on the date that they schedule it for (they don't worry that something like Daylight Savings might have kicked in by then).
* The system stores that time in UTC, no problem there
* When someone views the event, you can show them it based on the time on their device

So, in this way, if my home building is in Los Angeles and I am sitting in New York: I schedule an event for December 26, 2012 at 7PM at my building (7 PM Pacific Time). The system stores it as December 27, 2012 at 3AM (UTC time). Once I have saved it, if I look at my device it may say that the event starts on December 26, 2012 at 10 PM (Easten time). When I get home, it will say that the event starts at December 26, 2012 at 7PM.

Right now, the original scheduling is being based on where the original person is, but you are scheduling an entire location (or at least a room). That just seems wrong to me, but I am just one person.

RBeatse wrote:So, in this way, if my home building is in Los Angeles and I am sitting in New York: I schedule an event for December 26, 2012 at 7PM at my building (7 PM Pacific Time). The system stores it as December 27, 2012 at 3AM (UTC time). Once I have saved it, if I look at my device it may say that the event starts on December 26, 2012 at 10 PM (Easten time). When I get home, it will say that the event starts at December 26, 2012 at 7PM.

Mixing one time zone used for entering events with a different time zone used for displaying events seems hopelessly confusing. Under your proposal, you'd be looking at all sorts of existing events, all adjusted to the time zone your device is currently using. Then you add a new event that fits in with those events, but you specify that event in the time zone of the building, only to find that when you save it, the time suddenly adjusts to be in the time zone of the device.

To give an example, I want to schedule a meeting that starts one hour before my block that is at 9:00am PST. I am in EST, so my block appears as noon EST. So I have to think of my new event as being at 8:00am PST, even though it is one hour before the event that appears at noon on the calendar I'm looking at right now. So I figure that out and create an 8:00am event. I save it, and it is immediately displayed as 11:00am (PST). I edit it, and it appears as 8:00 again. I don't see how mixing time zones can work at all.

RBeatse wrote:I read the other post and I guess I am going to have to respectfully disagree about it being the only way it can reasonably work. Here is how I believe it should work:
* Each Location is assigned to a time zone (the time zone of the physical building)
* When a person schedules an event, they are choosing the time that they want the event in the location where the building is on the date that they schedule it for (they don't worry that something like Daylight Savings might have kicked in by then).
* The system stores that time in UTC, no problem there
* When someone views the event, you can show them it based on the time on their device

I disagree with your last point. And I would make one change - each ward and stake is assigned a time zone. The reason for this is to deal with locationless events. But all events are based on the unit time zone, regardless of what time zone the viewer is located in.

I find it difficult to belive that people think in terms of "thier local zone" and not "the ward's time zone" when looking at events.

I see the problem but I don't think it is any more onnerous than having it the other way. In your example, your block starts at 9 AM and someone calls you top schedule something at 8 AM. You schedule it at 8 AM but to the whole Ward, it looks like ti is at 5 AM, just because your phone is set to Eastern time.

I don't know...It just seems like there better way. I know that for work, eveyone else isn't affected because I happen to be in a different tiome zone when I scheduled a mtg. There needs to be a constant and I would think that it should always be the building time zone. I schedule things base don the building's time zone...not based on where I happen to be at the moment. Maybe the best could be some kind of notification that shows the time at the building for whatever you are scheduling so that these things don't get confused but maybe that is only a problem for a very small group of us and I'll get over it.

RussellHltn wrote:I would make one change - each ward and stake is assigned a time zone.

I have not lived in a ward that covered two time zones, but I have lived in a stake that covers two time zones. I think the assignment would have to be by building, not by ward/stake.

(And to make it even worse, the half of the stake in one of the time zones did not observe daylight saving time.)

lajackson wrote:I think the assignment would have to be by building, not by ward/stake.

What about location-less events? For that it should be by ward which I would expect to be determined by their normal building. (Oh, I can see the fun now if they move buildings.....)

But location-less for stakes is a bit trickier. Would it be by the stake center?

RussellHltn wrote:What about location-less events? For that it should be by ward which I would expect to be determined by their normal building. (Oh, I can see the fun now if they move buildings.....)

But location-less for stakes is a bit trickier. Would it be by the stake center?

At first consideration, I would think the ward or stake meetinghouse would be a good default. Until, of course, the stake has a youth activity in another city. I just don't think the programmers can win on this one. [grin]

I can see RBeatse's issue as it relates to those traveling away from their ward/stake's time zone. And I think it is a factor whether creating events or just viewing event times when physically located in another time zone. When a traveler looks at the calendar online they expect to see the event times in the time zone for which the event will occur and not the time zone in which the traveler may be at the moment when viewing the calendar. This is no different than a paper calendar of events which is printed and taken with a traveler. When the paper calendar is viewed while in New York it still shows the event times as they were printed in Salt Lake City. Should I add an event to that printed calendar I would write in the time using the same time zone as all the other events on that printed calendar and not using the time zone I am currently in.

When I travel and I am planning to attend an event for my ward I think of the event time in reference to the location the event is going to occur and not in reference to the time in the time zone I am physically in.

This idea of displaying the time for the event location can be accomplished to accommodate travelers such as RBeatse. The calendar program can be programmed to adjust time displays for a unit location. When a traveler is away from their home time zone the calendar can display a message that tells the traveler that all times are in [home unit time zone]. It is a matter of comparing the time zone the user's computer is in to the ward time zone.

There are times applications need to display times for the time zone the device is located. And there are times when applications need to display times for one location. I think the calendar should use the latter.

While I was composing post #10 I did not see posts #7 - #9. But I think this can also be addressed through programming. It requires an additional input during event creation to identify the event location time zone if different from event creator's home ward location time zone. And it requires additional display information that tells the viewer of the time zone difference between the event location time zone and the home ward location time zone. There are two options that I can think of right now. Display space comes in to play for both. So that is a consideration on a calendar that already has to deal with limited display real estate issues.

lajackson wrote:Until, of course, the stake has a youth activity in another city. I just don't think the programmers can win on this one. [grin]

How is that being handled now? In Calender 1.0? Or how was it handled in the days of paper calendars?

I'm not sure as the answer is all that complex.


It's interesting that so far there's not one defender of the existing situation. I can think of another problem - mobile phones. Typically they get their time information from the cell tower. If you're close to the border of the time zone, it could be off. And the user may not be aware what time zone their phone is currently operating in.

Just to repeat what jdlessley said:

When I travel and I am planning to attend an event for my ward I think of the event time in reference to the location the event is going to occur and not in reference to the time in the time zone I am physically in.

RussellHltn wrote:It's interesting that so far there's not one defender of the existing situation. I can think of another problem - mobile phones. Typically they get their time information from the cell tower. If you're close to the border of the time zone, it could be off. And the user may not be aware what time zone their phone is currently operating in.

I guess you weren't paying attention to my posts on this topic. Although I can certainly understand why some people might not like some aspects of how it works now, I think it is the only possible way for it to work, if you have to choose a time zone to display based on the information currently available (time zone of the buildings involved, and time zone of the device you're viewing the calendar on). I could see some potential for jdlessley's suggestion that an additional time zone selector be provided in the user interface.

My argument is based on a couple of key points:

• This is the way Google Calendar, Outlook and a wide variety of other widely-used calendars work. Events are stored in UTC, and are displayed using the time zone of the device you are viewing the calendar on. I don't understand why people think the LDS.org calendar should be different from these very popular calendaring systems.
• Synchronization will synchronize the actual UTC time of the events. And mobile phones in particular (one of the main use cases for sync) will usually automatically change the time zone on the device. It makes no sense for a synced calendar to try to maintain a different time zone for events, when those events will almost certainly be displayed alongside other events on the mobile device that are stored in UTC and displayed in the current time zone of the device.

RussellHltn wrote:Just to repeat what jdlessley said:

When I travel and I am planning to attend an event for my ward I think of the event time in reference to the location the event is going to occur and not in reference to the time in the time zone I am physically in.

For me, it depends on the event. If I am going to physically attend it, I might agree. But I disagree if it impacts me in a different way; e.g., I am calling in to a presidency meeting, or I'm thinking of calling home, but looking at my calendar shows me that my family is at the ward activity.

aebrown wrote:I don't understand why people think the LDS.org calendar should be different from these very popular calendaring systems.

I'll try once to explain why I, at least, think it should be different and then I'll give up (or at least I'll try to give up):

On your mobile device, things like Google calendar and Outlook and such change the times because the central piece that you are scheduleing (yourself) is changing time zones. I make a calendar entry to go call someone at 6PM and it changes the time to match where the central feature (me), changes time zones so that the call still happens at 6 PM.

Here, though, the central figure to be schedule is not me. It is a building and that building is not changing time zones. So we are saying, when I schedule something to be at 6PM to the Central figure (the building), then that building's schedule should not change. If you want to say that it should display the time based on my device's clock, then fine (though others have said it shouldn't do that either). But, the time scheduled should be based on the time in the location where the building is becuase it is the thing being scheduled, not me.

I know when I look at a building calendar that says the meeting is at 7PM, I assume that means in Salt Lake (for me) and I can adjust the time based on wherever I am.

Ultimately though, you seem pretty passionate about it and so since you're the moderator, I guess you win regardless of how much everyone else thinks there needs to be a change.

RBeatse wrote:Ultimately though, you seem pretty passionate about it and so since you're the moderator, I guess you win regardless of how much everyone else thinks there needs to be a change.

I don't see how that comment is warranted. If you review the thread, you'll see that three other people have chimed in (all moderators or administrators), and they pretty much agree with you. I certainly appreciate the opinions you are sharing, and I think you have a good point when you note the perspective of the building being scheduled rather than a person. That argument doesn't change my mind when I weigh it against the totality of the factors, but it's certainly a good argument.

Besides, none of us controls the development of the Calendar application -- we're just expressing our own opinions. So I really don't understand your "I guess you win" comment.

RBeatse wrote:so since you're the moderator, I guess you win regardless of how much everyone else thinks there needs to be a change.

We're more like the member clean-up crew that cleans the chapel on Saturdays. We do some work to help out the "FM Group". We hold some sway because we're active and been here awhile, but not as much as our titles might suggest.

aebrown wrote:I don't see how that comment is warranted. If you review the thread, you'll see that three other people have chimed in (all moderators or administrators), and they pretty much agree with you.

My apologies. It was a long day of troubleshooting a system outage and I posted before thinking through my response. Thanks for your moderating!

I mentioned this topic to my wife and she gave this example....lets say that this same system was being used throughout the church buildings. President Monson is traveling in Germany and asks his assistant to schedule a meeting in the First Presidency's conference room for the following Tuesday at 9AM. Bro. Hales opens his iPad and opens the schedule. Should he have to know the time difference between Berlin and Salt Lake (and schedule the meeting for Tuesday at 5pm) or just schedule the room for Tuesday at 9am?

We're aware of the time zone "concerns" in Calendar and it's on our to-do list for implementation in a future version of Calendar. Thanks for your input.

I think the fix for this is to more easily display what timezone on the "when" part of creating a event. If it was displayed more simply.

the other option is to allow you to pick a timezone for your account or select use computer time. We would have to think about that but is we had for example MST next to the time when you create then when he is in another timezone he sees EST then it would at least given the user more information.

Personally, I'd just be happy with a display (and possible selection) of time zone on the main calendar page. That's going to be the point where most will go "what the ...". I think most will understand that a setting on the main page will carry over to all sub-pages.

Displaying the time zone when creating each event is a nice touch, but how would that work when you're creating an event that's on the "other side" if DST? Would it be MST or MDT (as appropriate for the event date entered)? Seems like that's going to be harder to code.

As I was thinking about this last night, it actually makes sense if there could be a check box at the top of the calendar that lets you choose to see the events in "device time" or in local unit time (which would require knowing what the time zone of the buildings are). Then a person could choose how they interact with the calendar.

RBeatse wrote:As I was thinking about this last night, it actually makes sense if there could be a check box at the top of the calendar that lets you choose to see the events in "device time" or in local unit time (which would require knowing what the time zone of the buildings are). Then a person could choose how they interact with the calendar.

I was thinking more of a drop down list where the top selection would be "device time zone". But when the drop down list wasn't displaying the selection list, it would show the zone in effect. (Either the time zone set, or the reported time zone of the device.)

Of course, this assumes that people understand the concept of zones as used by the system. Not MST/MDT, but the zone that defines when DST starts/ends. Some people are going to be unhappy they can't find their state listed.

russellhltn wrote: Of course, this assumes that people understand the concept of zones as used by the system. Not MST/MDT, but the zone that defines when DST starts/ends. Some people are going to be unhappy they can't find their state listed.

You make good points! Maybe this is just going to be my issue since most don't travel enough that it matters.

Thanks. I tried to think of a way to stick with MST/MDT, but when dealing with "month view" you just can't. So I think the choices will have to be (to use the Win7 list for UTC-7):

(UTC-07:00) Arizona
(UTC-07:00) Chihuahua, La Paz, Mazatlan
(UTC-07:00) Mountain Time (US & Canada)

Individual events can be tagged as MST/MDT, but that would take more coding (and testing) to make sure it works world-wide.

I think the problem with "local unit time" is some stake span time zones. Not all wards are in sync. So there may be some question "what zone is that" when looking between local unit events and stake events.

russellhltn wrote: Individual events can be tagged as MST/MDT, but that would take more coding (and testing) to make sure it works world-wide.

I think the problem with "local unit time" is some stake span time zones. Not all wards are in sync. So there may be some question "what zone is that" when looking between local unit events and stake events.

Definitely don't want to add a lot more coding and testing. My first response to your second point was going to be that once again, although a Stake may cross time zones (what a headache that must be), the building itself that is being scheduled does not...at least I hope not!! However, I can't imagine being a Stake President and having to remember which building is in which time zone on the calendar and if he needs to adjust his own time of arrival. Man, this world domination thing is tough!!!

I, respectfully, conceded the point. More people would be affected negatively by making the change than I think are affected today using the device time. A lot better developer time can be put to issues like repeating events and an audit log, amongst others.