I suggest dealing internally with UTC as much as possible, and treating time zones as an "I/O formatting" concern. But ironically the big exception I know of is scheduling future events in calendars! The reason it's a problem there is that if you schedule a meeting, the app converts it to UTC, and then the timezone rules change, your meeting will be at the wrong instant. So it is important to keep the original input string (or at least the originally requested local time).
I guess the moral is that timezones are not easy. :-)
1. The user in California saves a meeting at 7am for June 1, 2017. (Today is April 17.)
2. You convert to UTC (-0700) and save that in your database.
3. On May 1st California decides to stop observing Daylight Savings Time effective immediately. Your server automatically updates its system-wide timezone file so it knows about this change. Now that UTC date in your database is happening at 6am instead (-0800). The instant hasn't changed (The meeting is still happening at the same moment in e.g. Paris.) but the user probably really wants it to stay at 7am. They are going to be annoyed if their colleagues dial in while they are still in the shower. :-)
I hope that helps!
For example, "America/New_York" is a standard identifier for a geographic area. Depending on the date, it is either 4 hours or 5 hours behind UTC. That is what we call daylight savings time, and it controls whether America/New_York uses the "Eastern Standard Time" (EST; GMT-5) or the "Eastern Daylight Time" (EDT; GMT-4) time zone.
If those political rules change, and you threw away the local time zone info as it existed when the record was created (because your app converts everything to UTC) then users will get the wrong times for their events.
If you have an event scheduled for next year, and the rules change, do you need to modify the display of that event? How do you know which appointments on the calendar have been updated to follow the new rules?
You have version 1 of your software, then the rules change, so you release version 2. That updates dates on first launch. You have an unrelated bug, and release version 3. what happens to users that upgrade from 1 to 3?
Time handling has a bunch of funny edge cases anyway, even without DST. Those projects often end in tears.
Friday => UTC to local time is 7 hours.
Monday => UTC to local time is 8 hours.
Even then, it's still not clear-cut enough for computers to guess. Imagine the following facts are presented in this order:
1. "It is a Friday, and I am in London right now."
2. "On Tuesday I have an incredibly important [X o'clock] phone-call with someone here in the London Office."
3. "I am traveling to Prague on Monday and returning on Friday."
As a human, can you tell when the phone-call is? Did the traveler intend wall-clock X "here" in London, or did they mean wall-clock X wherever they'd physically be in the future? If it's that ambiguous to a human, do you want your software to make fancy guesses?
(Bonus: "The Czech Republic is ending their Daylight Savings time this Sunday.")
It could also prompt for timezone if Event.GeoTimeZone != CurrentTimeZone ?
Finland is E.U. and has a 2hr time difference. The EU doesn't mandate a time-zone.
The author says you should assume the time zone of where you will be when that time occurs, but that's certainly not a safe assumption, as I may schedule a call at my Boston office for a certain time, but then may be traveling during that actual trip but the time should still be Boston and not where I'm traveling. I use Google Calendar backend but only interact through my Mac or iPhone using iCal or Fantastical both which support time zones. So for most people who time zones isn't an issue, its not a problem. For people who travel often or who have clients in different time zones, you simply add a couple keys when creating a smart entry in Fantastical. Just like when I'm talking to client who know are in a different time zone I always mention the time zone after the time.
It's not even assumption which is guaranteed to have a unique answer, much less the correct unique answer. It's possible for a person to experience the same time local time (on the same local date) in more than one time zone when travelling.
Heck, it's possible to experience the same local time on the same local date twice without travelling during DST or Summer Time transitions, and while most people don't have events scheduled then, people who do might work might.
Suppose I'm coming back to Chicago from a trip to Japan, and a friend wants to get an early dinner when I get back. One frequent direct flight from Tokyo leaves NRT around 6 PM and arrives at ORD at 4 PM on the same calendar date. Before I leave Chicago I set an event for meeting them at our favorite restaurant at 5:30 PM. Should my calendar remind me about the event when it's 5:00 PM where I'm at waiting for my flight to board at Narita or at 5:00 PM where I'm at back in Chicago?
A possible solution might be to ask the user to switch event times when a time zone switch is detected. Also, the computer can ask for clarification if the location of an event can be detected at creation time (i.e. it knows your travel itinerary or location of the event).
One of our internal scheduling tools used Google Calendar as the backend but had a custom frontend, It was to schedule a service call and the scheduler didn't actually care who made it as long as someone did at the appointed time so the frontend aggregated multiple calendars and displayed all free times. Most of the people being scheduled were in New York, but a few were in Arizona. Intermittently people in New York would complain about not being able to schedule after 5 pm EST on Friday. Refreshing the page sometimes fixed it
Certain it had to be a timezone bug I put off working for it for as long as possible.
tl;dr; The people in Arizona had all day blocks on the weekends. The all day events had no timezone because the calendar has it. The default timezone in the library I was using sets the timezone to GMT. 5 pm EST is midnight GMT. So after 5 PM Friday it looked like no one in Arizona had free time.
It was intermittent because as a form of load balancing the service calls I had randomized which calendar I tried to schedule first.
The team in Arizona was dissapointed when I finally fixed it.
This did happen to me with daylight saving a while back so I do sympathize.
assume that “4pm” means “4pm in whatever time zone we find ourselves in when the appointed day arrives.”
Alternately, suppose the user changes their destination to another country in another timezone: Does the phone call get rescheduled to another absolute time?
(Also, the date it also time zone dependent, so...)
Moreover, meetings across offices may have rooms booked in many locations; how do you know which is for whom? If I want to book a meeting for next week, and I'll be in NY, but I'm in SF now and someone from SF is dialing in, how does it know which time zone to use?
> You can set the time zone on an event by event basis.
>> At least, until we learned to painstakingly enter the time zone for every calendar entry by hand (even now, I often forget).
What is mentioned however is the TrueTime API that models `Clock.now()` as intervals rather than a fixed timestamp.
I'm going to start with an assumption that for the most part Google knows where you are and where you'll be. (Assume it has access to your email / flights / other appointments etc.) An appointment also has access to who is important to the entry.
I'm currently on PDT, will be traveling to CDT and have a phone appointment with someone in MDT later this week. A good user interface for this would show all three times so that I can intelligently talk about the appointment either in an email or on the phone. This is what I mean by 'added context'. UTC is fine for storage, but the who and where is generally interesting (even if you're looking back on things later).
This problem seems like it has a simplification to a common fallacy that a single representation of any fact is the only way to display information. I'm not sure it would be significantly too much effort to make a 'super intelligence' understand that.
Their hand might be tipped even before that, when the AIs connect with weapons suppliers on LinkedIn during the planning stages.
In Russia there are 11 time zones. When somebody moves from Irkutsk to Chelyabinsk by train, the arrival and departure times for trains on all stations are _always_ stated in Moscow time zone.
Scott Aaronson haven't visited International Space Station yet. Do you guys know what time system is used on board of ISS? And how they arrange time of the meetings with somebody on Earth?..
In a fair number of cases, this actually works and in the rest people are often so badly buried that they think it's too late to switch.
...you live your day by UTC?
At work we have two local relevant times in the office - GMT and Europe/London. Some programs are scheduled at GMT (world service), sometimes they're in UK time (national news).
Some computer logs are in GMT, some are in local time. It's a right pain - if we were 4 or 5 hours offset from GMT it wouldn't be a major problem, you tend to know roughly what time you're looking at, and you'd only have wall-time or GMT. GMT and BST are too close together to be unambiguous though.
Colleagues working in Washington tend to be 5 hours behind regardless, those in singapore are 7 or 8 ahead. Some countries I give up with completely
Specified GMT or UTC doesn't always halo as some people assume you mean "time in London". UTC is better in that regard, but it would be easier if UTC was several hours away from civil time.
But still, can one set UTC as the default for time entry in Google Calendar?
Cool. So can display time be set independently?
This sounds like an oxymoron to me. If it is superintelligent( i.e. smarter than a human) then it would not be tripped by a simple thing like this.