
If Google achieves superintelligence, time zones will be its Achilles heel - malmaud
http://www.scottaaronson.com/blog/?p=3221
======
pjungwir
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](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-...](http://stackoverflow.com/questions/16946002/javascript-time-zone-is-
wrong-for-past-daylight-saving-time-transition-rules) [2]
[http://jsbin.com/zicomitoka/edit?html,js,output](http://jsbin.com/zicomitoka/edit?html,js,output)
[3] [http://momentjs.com/timezone/](http://momentjs.com/timezone/)

~~~
foota
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?

~~~
pjungwir
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!

~~~
pjungwir
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.

------
Terr_
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.")

~~~
pavlov
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?)

~~~
dijit
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.

~~~
wolf550e
'pavlov meant that the entire EU switches to daylight savings time on the same
date.

~~~
dijit
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.

------
heavymark
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.

~~~
dragonwriter
> 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.

~~~
truthexposer
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.

~~~
ekiru
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?

------
surfmike
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).

------
spullara
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.

------
arthurjj
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.

~~~
pcmonk
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.

~~~
arthurjj
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

------
asrp
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.

~~~
tromp
The article suggests:

assume that “4pm” means “4pm in whatever time zone we find ourselves in when
the appointed day arrives.”

~~~
Terr_
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?

------
faitswulff
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."

~~~
wfunction
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).

------
bearcobra
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.

~~~
maerF0x0
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.

------
joshka
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.

------
a3n
> 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.

~~~
itburnslikeice
Ai: 4x Missiles, 100xBullets at <address>, here is the Bitcoin Supplier: mkay

------
avmich
Sigh.

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?..

------
mirimir
So why not just use UTC everywhere?

~~~
wfunction
> So why not just use UTC everywhere?

...you live your day by UTC?

~~~
mirimir
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.

~~~
wfunction
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.

~~~
mirimir
True.

But still, can one set UTC as the default for time entry in Google Calendar?

~~~
wfunction
Yes? [https://calendar.google.com/calendar/render#settings-
general...](https://calendar.google.com/calendar/render#settings-general_11)

~~~
mirimir
OK, thanks. Except Mirimir has no Google account.

Cool. So can display time be set independently?

------
resonantjacket5
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?

------
eng_monkey
Is it really 'superintelligence' if unable to deal with a simple concept such
as time zones?

------
felipemnoa
>>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.

