Remembering the dark time (zone?)
Flash-forward to April 2017, when Amazon dropped the Device Address API. This feature allows developers to gather location data for the device they're interacting with, either as a physical address or as a postal code. And therein lies the problem with using it as a vector for gathering timezone. If the lack of a solution was like trying to crack a walnut with your bare hands, the Device Address API was like using a sledgehammer. It gave way too much, and too granular, detail, and along with that came everything else that comes with handling PII - Permission Cards (also clunky), Privacy Policies (otherwise optional), and user avoidance due to perceived overzealous permission escalation.
The Users Make Their Case
So, yeah, it was obviously a highly desired feature.
Twitter weighs in
It's X-mas in August #VoiceFirst crew!!https://t.co/bEb5lF3LxP
— Memo Döring (@memodoring) August 21, 2018
But my birthday was yesterday :)
— Charles LaPress (@chucklapress) August 21, 2018
Alexa developer heads around the world exploding. Timezone API finally released.
— Bob Stolzberg (@BobStolzberg) August 21, 2018
But what IS the feature, even?
So, on further review, what have we actually been given? Timezone is what people were clamoring for, but that was only one piece of what we actually got - default unit of temperature and distance are also options you can request. There hasn't been nearly as much feedback about the need for those properties, but it made sense to tack them on while tackling the timezone problem... maybe.
You see, the way the feature was built is actually a little bit different than what was requested, and what we all expected would happen. The sort of de facto shared notion of what this would eventually look like was that it would be a field that would come in on every request, much in the way the Locale field does today. Given that they are both vaguely geographic data, and that they are reasonably ubiquitous (presumably all devices have a timezone, default or otherwise), it would've been a natural progression of the Alexa request object.
Instead, what we have is a new endpoint on the Alexa API, which can be accessed via a GET call with the user's apiAccessToken (which comes in on every request). The request URL includes the deviceId in question, and the response is a plaintext string describing the value of the property requested. It's an extremely simple endpoint, and should be trivial to integrate against.
The major con to this approach is that the skill doesn't just have the timezone information natively, it has to actively seek it out via an API call. Even worse, the endpoint as implemented provides no way to get all settings at once, so if you need two or three of these properties, you're waiting on two or three roundtrips. In a case where a tenth of a second might be the difference between a user not noticing a delay versus a user getting frustrated at how long they're waiting, that matters.
But there are also some pros. Doing it via an API call means that any time you have the access token, like maybe in the case of a push notification workflow that happens outside of the normal interaction model, you are able to get timezone. This is something that could be super relevant in the case of AstroBot, for example, where timezone ambiguity for an upcoming launch event could easily cause people to miss it.
Maybe more importantly, this approach allows the endpoint to be easily extensible, and I suspect Amazon might have a very good reason for being interested in that...
Some sort of timezone pun about the future... you guys get it...
At one point, however, I had a discussion go a different direction, where instead I suggested to the Amazonian I was talking to that maybe a shared preferences system, which persisted from skill-to-skill, would be a way to mitigate the lack of a cross-skill id. Something with a limited enumeration of properties that were likely to be applicable to many skills. A user in one skill could assert that they were comfortable hearing profanity, and other skills could take that into account without having to run the user through a preferences setup, for example.
And what we have today with this settings API looks an awful lot like the theoretical approach I proposed. That's not to say that they will use it that way, but they certainly could use it that way with very little technical effort. And even if there's never anything configurable from within our skills, I could certainly see a case where a little bit more information is revealed about the user's settings.
As a developer, wouldn't you like to know whether a user had Alexa Brief Mode enabled? I know I would.