zeroclickinfo-goodies
zeroclickinfo-goodies copied to clipboard
SunInfo: Needs to check if Daylight Savings is in effect and adjust answer
Searching "sunrise" correctly brings up the sun times for my location, but the times appear to be early by one hour.
Actual sunrise is about 7:50am, sunset is about 5:02pm today.
Maybe a DST issue?
IA Page: http://duck.co/ia/view/sun_info
Just realised that there are 2 IAs for sunrise/sunset timings.
SunInfo: https://duck.co/ia/view/sun_info [Goodie] Sunrise/Sunset: https://duck.co/ia/view/sun_rise_set [Spice]
Perhaps we should combine the two? Probably into the Spice IA since that pulls the data from timeanddate.com which should be updated with DST taken into consideration.
@jameskoole https://www.timeanddate.com/sun/canada/toronto should be correct...
@altern8tif the reason we use two different IA's is that we've had relevancy problems with the TimeAndDate API identifying a location based on the $loc
object we have for a user. So it really only support queries for sunrise in <country>
or sunrise in <capital_city>
. We check a list of names against the query and only show an answer if its one of those, so we know for sure the location will be correct.
The Goodie on the other hand, users the user's timezone (rather than location) to calculate the sunrise/sunset.
Ultimately I'd prefer to use the API (so we're not doing the math), but the problem is location relevancy, which is a larger problem we need to fix
@moollaza Noticed that the TimeAndDate API allows lat/long queries.
So you're saying that the user coordinates passed from the $loc
object into the T&D API, doesn't return a usable location to output our sunrise/sunset data?
So you're saying that the user coordinates passed from the $loc object into the T&D API, doesn't return a usable location to output our sunrise/sunset data?
I'm not sure if we tried that. If we could use T&D for sunrise
and sunset
then it would simplify things!
https://sunrise-sunset.org/api
http://stackoverflow.com/tags/timezone/info
@DGMurdockIII thanks for the links, adding some context would be helpful though. I'm not sure what you're getting at with the second link.
Unfortunately, that API isn't going to work for us because the Lat/Long we have for the user is generalized and therefore not very accurate.
@moollaza There is no need to calculate or guess the time zone. The browser sends the time zone in the date header of the request. https://en.wikipedia.org/wiki/List_of_HTTP_header_fields
Running this locally with duckpan gives the correct data:
$ duckpan query SunInfo
Loading Instant Answers...
(Empty query for ending test)
Query: sunset
You entered: sunset
---
DDG::ZeroClickInfo {
Parents WWW::DuckDuckGo::ZeroClickInfo
public methods (4) : DOES, has_structured_answer, new, structured_answer
private methods (0)
internals: {
answer "On 20 Oct 2020, sunrise in Seattle, Washington is at 7:36 AM; sunset at 6:10 PM",
answer_type "sun_info",
caller "DDG::Goodie::SunInfo",
is_cached 0,
is_unsafe 0,
structured_answer {
data {
rise "7:36 AM",
set_data "6:10 PM",
sunrise_svg "/share/goodie/sun_info/999/sunrise.svg",
sunset_svg "/share/goodie/sun_info/999/sunset.svg",
when_data "20 Oct 2020",
where "Seattle, Washington"
},
templates {
group "text",
item 0,
options {
content "DDH.sun_info.content",
title_content "DDH.sun_info.title"
}
}
}
}
}
---
our %locations = (
'us' => {
country_code => 'US',
country_code3 => 'USA',
country_name => 'United States',
region => 'WA',
region_name => 'Washington',
city => 'Seattle',
postal_code => '98144',
latitude => '47.6062',
longitude => '-122.3321',
time_zone => 'America/Los_Angeles',
area_code => '',
continent_code => 'NA',
metro_code => '504',
loc_str => '98144'
},
But the same query on duckduckgo.com is still incorrect.
Either some libraries are out of date or the mysterious source of $loc
isn't getting filled properly
On further investigations it looks like $loc->time_zone
is incorrect since unixtime
also gives the wrong timezone for the third row, giving the non-dst timezone offset.
Related: #3863, #4699