Time zones

A time zone is a geographical region where local clocks are always synchronized.

The time of an event can be defined in three ways:

In a time zone 

This is the normal way when the event has a location. The event's time zone matches the geographical region of the location.

For example, you arrange a meeting in New York. That event's time zone must be US Eastern Time.

Calendar does not currently support this.

In universal time (UTC) 

This is for when an event has a specific time, but no location. It is unusual.

For example, a group of world travellers agree to chat together on the Internet on a future date at 1000 UTC. On that day they will all be in different time zones, which they cannot predict. So the event itself has no location, but it does have a specific time.

Calendar has a setting to support this.

Floating 

This is for when an event is always in local time. It is unusual.

For example, you must take medecine at midday every day, no matter where you happen to be. You set a repeating alarm for 11:55 a.m. floating time. As you travel the world, the alarm always pops up just before midday local time.

Calendar supports this by default. If you stay in the same time zone, you do not notice that the times are floating.

Displayed times

Calendar currently displays all times in the operating system's time zone. This is OK for most users. It is not OK for people who travel between time zones, or who share their calendars with people in other time zones.

For example, you normally work in Los Angeles. You are arranging a business trip to New York next month. You want to see your LA events in local time (US Pacific Time), but you want to arrange your schedule in New York in US Eastern Time.

Your colleagues in NY arrange a meeting there to help you plan your trip. You join the meeting by telephone. The meeting is in NY, but you want to see it in LA time (where you will be calling from).

Usually you need to see an event in the time zone where you will be when the event takes place. This might not be the event's time zone, and it might not be the time zone where you are now.

Sometimes you need to see the event's time in its own zone (if it has one).

Sometimes you need to see events from the point of view of some other person in another time zone. (For example, when you make an international telephone call to discuss a schedule.)

Issues

• In what timezone should the datepicker be when editing an event? In the stored timezone or in the display timezone?
• Should editing show the timezone?
• calIDateTime.jsDate is always in the local timezone. Should it be banned?
• On the other hand, it is a way to get a date in the local timezone.
• In what timezone are events created by default?
• UTC events have issues with recurrance and daylist saving time. For example, 14:00 in UTC can be 12:00 or 13:00 in european time. Recurring every week at 14:00 UTC will change the time in european time. So UTC isn't a suitable storage for normal events.
• You are in California on the phone with someone in Boston planning a phone conference from 10:00-11:30am for next week at which time you'll be in Singapore. What time should you set the conference for? Can you do the math? How about if you're in Phoenix in April? There are 31 time zones and almost all contain some regions that observe and some that do not observe DST.
• You make a new friend on a visit a trip that includes a visit to Perth, Australia and London and put her birthday in your calendar. You get to San Francisco. What day is her birthday? All day events carry no timezone, because it is just on that day. No problem here.
• How to find out the timezone the user lives in? (in tzid format if possible)
• Calendar needs to support in-zone events.
• The in-zone/UTC/floating setting needs to be per calendar entry. (Currently, UTC is an option for the program as a whole.)

Suggestions

for editing:

• floating events show the floating time
• other timezones show in the display timezone
• not complete yet

for getting the default timezone + the ui:

• instead of the olsen list of timezones, just store the zones using their name, not their city (CET, PST etc)
• the name can be retrieved from the OS
• have a list of cities per timezone to present to the user
• It should be possible to get this data from the olsen data with some smart scripting

for comparison:

• look at other programs that have timezone support. For example, iCal has fantastic support for Timezones (very straightforward).

for display:

• Provide a location list that the user can customize (like the category list).
• Allow the user to specify the time zone at each location.
• Track the user's zone by using Journey events for planning trips. A Journey event is a non-iCal event that has a start location and an end location. Journeys allow Calendar to predict the user's time zone and use it display events correctly.
• Display each event in the user's predicted time zone at the time of the event. This way, remote events are automatically displayed at the correct times.
• Provide a button that temporarily displays everything in the user's current zone, or in some other specified zone.

Lookup precedence

calIICSService parses ical data. The lookup order for VTIMEZONEs is the following:

1. look for a parent VCALENDAR that has a referenced VTIMEZONE (corresponding the TZID).
2. Use the calITimezoneProvider that has been passed with calIICSService::parseICS.
3. Use the global calITimezoneService to resolve the referenced timezone.

Editing events and Timezones

• allday events are always floating.
  • If you want something that lasts all day, but in one specific timezone, make it last all day (00:00 - 24:00)
• New events are in the default timezone
• For now, existing events in a different timezone show a warning, and some UI allowing the user to select between original timezone and system timezone