If Google achieves superintelligence, time zones will be its Achilles heel(scottaaronson.com)
scottaaronson.com
If Google achieves superintelligence, time zones will be its Achilles heel
http://www.scottaaronson.com/blog/?p=3221
59 comments
So why not just use UTC everywhere?
Daylight savings time still gets screwed up.
Legacy thinking and practice. Many developers don't realize this is a hard problem, are used to tools with poor time zone support or defaults, over-estimate the cost of a database migration, or otherwise think they can save time by using whatever the local timezone is.
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.
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.
> So why not just use UTC everywhere?
...you live your day by UTC?
...you live your day by UTC?
I generally do, yes. I'm a consultant, working remotely. Using anything but UTC would be too confusing. Also, I use multiple online personas, and time zone is an information leak.
OK, well most people don't set their alarms for "12:00 +0000 (UTC) in the morning". They set it for 8:00 AM local time or something. So you're kind of an exception.
I do for half the year, being British.
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.
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.
True.
But still, can one set UTC as the default for time entry in Google Calendar?
But still, can one set UTC as the default for time entry in Google Calendar?
OK, thanks. Except Mirimir has no Google account.
Cool. So can display time be set independently?
Cool. So can display time be set independently?
> then, as often prophesied, Google’s deep nets achieve sentience and plot to take over the entire observable universe … and they would, if not for one fortuitous bug, which will cause the AIs to tip their hand to humanity an hour before they’d planned.
Their hand might be tipped even before that, when the AIs connect with weapons suppliers on LinkedIn during the planning stages.
Their hand might be tipped even before that, when the AIs connect with weapons suppliers on LinkedIn during the planning stages.
Ai: 4x Missiles, 100xBullets at <address>, here is the Bitcoin
Supplier: mkay
How would Google Calendar know the event is at 4pm in California? Is the location field filled with enough information? If not, that seems like almost as much work as entering the timezone.
This did happen to me with daylight saving a while back so I do sympathize.
This did happen to me with daylight saving a while back so I do sympathize.
The article suggests:
assume that “4pm” means “4pm in whatever time zone we find ourselves in when the appointed day arrives.”
assume that “4pm” means “4pm in whatever time zone we find ourselves in when the appointed day arrives.”
Unfortunately that's not a safe assumption either: Suppose the user is scheduling a phone call to reach someone who is back home at the location they haven't left yet.
Alternately, suppose the user changes their destination to another country in another timezone: Does the phone call get rescheduled to another absolute time?
Alternately, suppose the user changes their destination to another country in another timezone: Does the phone call get rescheduled to another absolute time?
[deleted]
What if you are travelling across time zones (or, for times that it would matter, experiencing a DST transition—or, for extra fun, doing both) on that day?
(Also, the date it also time zone dependent, so...)
(Also, the date it also time zone dependent, so...)
Then you are aware that the time changes and you already have to adjust your watch/pc/alarm clock.
It's called "floating" time. It means ignore the time zone completely and just display it as 4pm always. Alerts and whatnot would be based on your computer's current time zone, so if your computer is in PDT, it would display the alert at 4pm PDT, but if you set your computer to EST it would display it at 4pm EST instead.
I only enter locations in events for places that aren't where I'm already going to be. If I'm in the NY office, I don't bother to put NY in my reminders/events.
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?
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?
It sounds like the real problem here is that time specifications are fundamentally contextual, and for whatever reason the application either doesn't have enough machine-readable context to work with or doesn't use it.
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.")
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.")
Google already has a pretty impressive "Where" input field on GCal events, and consistently auto-suggests the correct address for an event.
It could also prompt for timezone if Event.GeoTimeZone != CurrentTimeZone ?
It could also prompt for timezone if Event.GeoTimeZone != CurrentTimeZone ?
London and Prague both follow the EU standard dates for DST, so at least there's a minor comfort that you can assume all of EU to switch at the same time. (Of course, after Brexit, who knows -- maybe they'll move DST start and end dates around just because they finally can?)
There's a 1hr difference between Prague and London.
Finland is E.U. and has a 2hr time difference. The EU doesn't mandate a time-zone.
Finland is E.U. and has a 2hr time difference. The EU doesn't mandate a time-zone.
'pavlov meant that the entire EU switches to daylight savings time on the same date.
Ah I see. And that's been a thing since 1996- it's unlikely Britain would switch to be spiteful as it doesn't add anything for Britain and only adds confusion. But I've been wrong about Britain and the EU before.
Couldn't this be easily solved by auto filling the time zone if you input the address (location) of the place? Like if I put in a californian address just prompt if I want the pacific time zone?
Time zones certainly won't be Google's super intelligence achilles heel, but certainly a good dramatic title to get people to read a bug report/feature enhancement.
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.
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.
> 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
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.
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.
What difference would that make? If different time zones give the same time, that makes no difference, as the time needed would be the local time. The local time could be in a twilight zone that works on a mod43 clock, but if you're scheduling an appt to be in the twilight zone at +800 twilight zone, +800 twilight zone will be the time you need to be at the place.
The problem isn't that multiple time zones give the same local time at a particular time; the problem is that a person may experience the same local time multiple times during a day due to traveling or summer time.
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?
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?
It's also possible to experience a particular local time zero times on the date for either of those reasons.
I agree that the calendar shouldn't make questionable assumptions. However, Scott's complaint is that he often forgets to set the timezone, resulting in significant harm. I think that it's a fair complaint--after all, the entire point of a calendar is to reduce your mental burden. Perhaps the best solution is to make the calendar explicitly prompt for the timezone if there is any ambiguity.
This is a problem unsolved by humans and is caused by not being specific enough. My human assistant who helps schedule things for me frequently has to ask clarifying questions to nail down the appropriate time and timezone. Even with that additional work it happens that one or more parties involved in the schedule failed to understand those questions and answer them properly.
You can set the time zone on an event by event basis. You can even set starting and ending times in different zones, which I do for flights. It's not hard - and hardly an "Achilles heel."
He knows.
> 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).
> 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).
I actually had a heisenbug related to Google calendar not caring about timezones.
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.
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.
Time zones in Arizona get extra exciting twice a year when the rest of the country jumps an hour for DST while we stay the same. Unless, of course, you're on the Navajo reservation, which does observe DST. Make sure you're not actually on the Hopi reservation, which is entirely surrounded by the Navajo reservation, because they don't observe DST.
Just in case someone reads this comment and thinks it's a joke, this is a real issue i.e. I've seen it cause issues in production
I gave a talk last year about a timezone strategy for Rails apps (or any app really). Sadly it wasn't recorded, so I'm hoping I can give it again somewhere, but here are the slides and source:
https://github.com/pjungwir/timezones-talk
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).
Another crazy timezone issue I encountered recently is that the Javascript standard originally told browsers to use Daylight Savings Time transition dates from the current year when deciding the timezone offset of days in past years. This has been changed, but in IE you still see the old behavior. [1] is a Stack Overflow answer+comments that mention this history. You can see the problem by loading [2] in multiple browsers. The fix is to use moment-timezone.js [3]---but make sure you download the file with historical data!
I guess the moral is that timezones are not easy. :-)
[1] http://stackoverflow.com/questions/16946002/javascript-time-... [2] http://jsbin.com/zicomitoka/edit?html,js,output [3] http://momentjs.com/timezone/
https://github.com/pjungwir/timezones-talk
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).
Another crazy timezone issue I encountered recently is that the Javascript standard originally told browsers to use Daylight Savings Time transition dates from the current year when deciding the timezone offset of days in past years. This has been changed, but in IE you still see the old behavior. [1] is a Stack Overflow answer+comments that mention this history. You can see the problem by loading [2] in multiple browsers. The fix is to use moment-timezone.js [3]---but make sure you download the file with historical data!
I guess the moral is that timezones are not easy. :-)
[1] http://stackoverflow.com/questions/16946002/javascript-time-... [2] http://jsbin.com/zicomitoka/edit?html,js,output [3] http://momentjs.com/timezone/
Following up because I need to write some time handling stuff in a side project. Could you elaborate on why a future date would cause a problem?
Sure! It is a rare problem, but I seem to recall a similar thing (at Facebook?) actually making the news not that long ago. Here are the steps:
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!
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!
That's extremely helpful, thanks!
EDIT: jfoutz gives a much more realistic example: maybe California doesn't give up on DST altogether, but just moves the start date. Note this is not really about DST at all, but DST stories probably make the best examples. Another example could be that China decides to create East and West timezones.
An important concept to have in your mind when dealing with timezones is that "Time Zones" and "Zone Identifiers" are not the same thing. "Time Zones" refer to an offset from UTC used to compute the local time; "Zone Identifers" identify a geographic region that has political rules about what its current time zone is.
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.
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.
Not the OP, but for example, the United States switched the day to start observing DST a few years ago. Individual states change their observation of DST from time to time.
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.
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.
[deleted]
I assume because of daylight saving times. It will offset the conversion.
Friday => UTC to local time is 7 hours.
Monday => UTC to local time is 8 hours.
Friday => UTC to local time is 7 hours.
Monday => UTC to local time is 8 hours.
This is true, but that wouldn't affect the scheduled time of an event.
Based on the articles I've read on Spanner it doesn't seem like time zones will hold them back, no matter how frustrating their calendar UX is.
My guess is AI will only use UTC. No timezones needed. Timezones are so humans can all get to work at 9AM no matter where they are on the planet. If humans were ok with getting to work at 12:00AM and eating "dinner" at 7:00AM etc it would be fine. Some timezone would look like usual 9-5 and the rest would adapt.
I doubt they do anything about TZ in Spanner since GPS time is not UTC (no leap seconds).
In fact, UTC isn't even mentioned once in the paper.
What is mentioned however is the TrueTime API that models `Clock.now()` as intervals rather than a fixed timestamp.
What is mentioned however is the TrueTime API that models `Clock.now()` as intervals rather than a fixed timestamp.
>>If Google achieves superintelligence, time zones will be its Achilles heel
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.
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.
This is a real usability issue but author's solution isn't really simple or correct. Your computer/Google calendar cannot definitely know your current time zone. (Imagine traveling but not having switched your computer's time zone.) Second, modifying all your events to be relative to your current time zone seems incredibly destructive — you may have events in your home time zone like conference calls, etc that you don't necessarily want converted.
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).
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).
A lot of the proposed solutions forget that this is a UX issue that can be addressed with the addition of more contextual information.
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.
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.
Is it really 'superintelligence' if unable to deal with a simple concept such as time zones?
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?..