Time: Timezone Based Searches

[pjhampton]

Description

There has been user feedback detailing the absence of time zone/time responses from DuckDuckGo. Queries include:

• eastern time
• PST time
• Pacific Time
• utc
• current utc time

I believe that these users might be expecting something like the following:

This would be super helpful! I'm not entirely sure what IA this is (maybe a new one?), but the closest one that I can find is the Time IA. There is also the Timezones Converter but this doesn't take into consideration the current time and time adjustments such as GMT -> BST.

Get Started

• [ ] 1) Claim this issue by commenting below
• [ ] 2) Review our Contributing Guide
• [ ] 3) Set up your development environment, and fork this repository
• [ ] 4) Create a Pull Request

Resources

• Join DuckDuckHack Slack to ask questions
• Join the DuckDuckHack Forum to discuss project planning and Instant Answer metrics
• Read the DuckDuckHack Documentation for technical help

---

Instant Answer Page: https://duck.co/ia/view/time

[pjhampton]

Please see https://github.com/duckduckgo/zeroclickinfo-spice/issues/1802 for related discussion on this issue

[BillyBarbaro]

It seems like perl has some support for converting between timezones, so doing this as a Goodie may be an option. Here's a gist demonstrating how it works and here's a list of the timezones (or maybe this is the list?) supported by perl.

As was discussed in the related issue, we'd need to create a mapping from the various queries to the correct identifier for the timezone in perl, but this could be done in a shared file like the Currency Spice currently has. I can start to imagine how this would work, but I haven't had any experience creating these. Do you think this would work?

[pjhampton]

ugh, yeah. @moollaza and I were running some experiments with the DateTime::TimeZone module on Friday, but the problem is that it only supports like 5 time zones. I created the following scratch:

use DateTime;
use DateTime::TimeZone;

my $tz = DateTime::TimeZone->new( name => 'America/Chicago' );

my $dt = DateTime->now();
my $offset = $tz->offset_for_datetime($dt);

I believe that Zaahir's original idea of mapping them as you mentioned. Do you want to work on a proof of concept? 😄

[BillyBarbaro]

Ha. Sure. It'll take a little bit of learning on my part (I've never written a Spice or perl code really), so it won't be super fast, but I'd love to give it a try. Sounds like a good opportunity to learn. Where should I put the code for it?

[BillyBarbaro]

Actually... New idea. Should've looked at the existing Time IA first. It's really nice. What if we just create a mapping between the time zone codes we want to support and a location that corresponds to them? Then when a query with one of these triggers the IA, it can search for the time in that location.

Then we'd tweak the front end code just a little to make sure it displayed the timezone instead of the city we mapped it to.

For whatever it's worth, the existing Spice already gives a response when you query What's the time in EST, but didn't really seem to work on other time zones.

[moollaza]

What if we just create a mapping between the time zone codes we want to support and a location that corresponds to them? Then when a query with one of these triggers the IA, it can search for the time in that location.

@BillyBarbaro that was my original idea to solve this. Given that Perl route seems like more work I think we should go with that solution. It's simpler and we know it'll work 👍

[BillyBarbaro]

@moollaza Sounds good. I've already been working on a bit of a proof of concept. I was thinking of storing the mappings similar to how it's done in the currency IA. Something of the form:

<Location1>,<Timezone String>,<Timezone String>, ... <Location2>,<Timezone String>,<Timezone String>, ...

Doing it this way, when a user searched for EST, it would result in the time in New York. I looked at the way google did it, and searching for both EST and EDT map to ET (Eastern Time). Would it be useful to include a standard name for each that we display in the IA? Or is it ok just to display the city we're mapping it to? If we need the name, I was thinking of storing it something like:

<Standard Name1>,<Location1>,<Timezone String>, <Timezone String>, ... <Standard Name2>,<Location2>,<Timezone String>, <Timezone String>, ...

Do you have an opinion here?

[BillyBarbaro]

Additionally, do you think this should be appended to the current Time IA or treated as a new IA? I feel we'd be better off creating a brand new one as this will just create a different path through the existing Spice which will make things a bit harder to understand.

[moollaza]

Would it be useful to include a standard name for each that we display in the IA? Or is it ok just to display the city we're mapping it to? If we need the name, I was thinking of storing it something like:

Yes, I think we should have standard names. That helps clarify to the user what timezone we interpreted the abbreviation as. It also means we can handle queries that mention the name, e.g. "easter time"

I would not mention any cities though, that will likely create confusion because there's no explanation where it's coming from -- the use of locations as proxies for the timezones shouldn't be mentioned to the user IMO.

do you think this should be appended to the current Time IA or treated as a new IA?

I think it could be added to the existing IA, but a new IA should be fine if you prefer 👍

[DGMurdockIII]

You can look at these two sites https://github.com/tamaspap/timezones and https://timezonedb.com/

[pjhampton]

Thanks @DGMurdockIII - We're currently using timezonedb. Gotta checkout timezones though 😄

[moollaza]

@DGMurdockIII @pjhampton We don't use TimeZoneDB, but it doesn't work for us anyways because users aren't searching for timezones with the city name, they look for the generalized time zone abbreviations: e.g. 'cet', 'est', 'edt', etc.

[pjhampton]

Ahh, thanks for the clarification @moollaza

[MrChrisW]

This is difficult, mostly because 3-4 letter time zone abbreviations are not standardised as part of ISO-8601. There's a discussion about this on the moment-tz project https://github.com/moment/moment-timezone/issues/289

Google seems to select the most commonly searched time zone to display when searching for "CST".

We could build a YAML file with a list of the top time zone abbreviations (mapping to an offset). However there will always be ambiguity! A decision has to be made about which timezone to display where multiple mappings exist.

As a MVP we could start with US time zones only:

• HST/HDT
• AKST/AKDT
• PST/PDT
• MST/MDT
• CST/CDT
• EST/EDT

[hughdavenport]

So some of these currently work, as mentioned before est, and i found that searching some countries also worked (new zealand, and australia (though this has multiple zones, but it picked canberra randomly)). So i guess we need to work out what does that currently and extend that?

[hughdavenport]

I would also be happy to help code, but new to project

[xplatform-dev]

assuming you can't rely on another service because it could be down: GeoIP to find where they are. PHP library: http://php.net/manual/en/ref.geoip.php Return most relevant result when time request comes in. Country codes should override GeoIP information for reasons I feel should be obvious -- "I'm in China, and I want to know what time it is in Cuba because that's where my family is." Language codes should override country codes since it's text being inputted by the user.

Since DuckDuckGo doesn't have country codes (duckduckgo.ca for example), use the language that is being processed if any? DuckDuckGo doesn't have to track someone to know that their last search was in French for example if the web page they typed in the request into had French in the URL.

Cookies, GeoIP, language, language codes, and country codes are the only ways to distinguish what the user wants. You would need to give the entire array of times. You could step up the game just a little bit and offer a map of the world that highlights the geographical area the user mouses over. This obvious would be disabled on no javascript version of the site.

[gargaml]

If we use a city name to get the time related to the requested time zone, we may have a problem with cities belonging to several time zones. For instance, because of DST, the city of Paris belongs to CET and CEST. I need to make more tests but I guess the timeanddate api will send different results depending on current DST.

If this is a problem, we can also add dst information to deal with it or we could consider that the user is already aware of these issues when making requests involving time zones.

[preemeijer]

Just want to let you all know that I also got feedback of no response when giving a timezone.

[pjhampton]

I'm going to time this out.

https://duckduckhack.com/