I've just installed the module. It's 11am and the current condition graphic shows night. The div class is called "yahoo-weather-night-bg" which leads me to believe that the module thinks that it's nighttime.
Have I set up the module incorrectly?
| Comment | File | Size | Author |
|---|---|---|---|
| #15 | 660364-ywf-day-nigh.patch | 1.42 KB | Pedro Lozano |
Comments
Comment #1
Pedro Lozano commentedI cannot be sure if it will fix your case but we have made modifications to take the current date from the data returned by yahoo instead of the date from the server.
Thanks.
Comment #2
axel pressbutton commentedHi Pedro,
I reported something similar in my post about the wind direction...but mine was the opposite - I keep getting random day images at around 22:00 - 23:30.
I'll install the latest update, monitor my situation and report back.
Cheers :)
Comment #3
HunterElliott commentedI'm getting the same issue - it's daytime and the module is displaying nighttime. It's like it's not interpreting the GMT offset for the site's timezone. (on a side note, the values displayed do not match Yahoo's values for the same zipcode - but that's probably another issue and will address it separately).
Comment #4
Pedro Lozano commented@HunterElliott:
The site timezone doesn't have to be taken into account as the information received from Yahoo contains the local time for the location selected. Anyway, we will continue to debug these kind of issues so any extra information is welcomed.
Can you give me an example for the zipcode issue? Remenber that the value you have to enter in the module config is not a zipcode, It must be the number in the yahoo url for that location.
Comment #5
HunterElliott commentedIt would be helpful, then, if one is to NOT use the zipcode of the city that you don't actually name the label of the field we're supposed to enter that value as "zip code of the city". And technically, your "help" line of "look up a city, the code will appear in the url." is not correct, either. For example, in Philadelphia the URL info from Yahoo may say "philadelphia-12765508" when your module seems to want only "12765508".
Comment #6
Pedro Lozano commentedYou are right about the label. I missed that.
The help text was correct before the last Yahoo API update where they changed the url pattern. We will have to change that too.
Thanks.
Comment #7
klonosHaving the same issue, but it isn't limited to only what the issue's title states. It also does the opposite. Perhaps change the issue's title to 'Incorrect day/night image' or 'Incorrect part of the day displayed' or something?
Also, this happens to the latest dev I'm using.
Anyways... subscribing to see how this'll go.
Comment #8
axel pressbutton commentedHi Pedro,
I've just noticed that I'm now getting Night images during the day...the strange thing is, I've not noticed any day images at night recently here :S
Please let me know if there's any testing etc I can help with. My location is Bath, UK and I'm using 12056 as my code
A friend of mine who I recommended the module to is also having the same issue, the location he is using is for Fethiye, Turkey 2343991
FYI, both of our servers reside in Germany but I don't think this will really matter in our situation.
Thanks again for any help
Comment #9
klonosHow can we display the time (that is if it is retrieved along with the rest of the information from yahoo)? That would help us troubleshoot this because it is getting really annoying :(
Is the information updated by cron runs or by each page load?
Comment #10
klonosbtw... I took a quick look at the code and realized that we retrieve 'sunrise_sunset' from yahoo. Can't this be used to determine whether it is day or night?
... Just a thought.
Comment #11
klonosoops... we already do:
... [scratching head]
Comment #12
klonosHey people, just a question here: Do you all having this issue here use Poormanscron (as opposed to the system cron)?
If yes, then I believe that this related issue might be the cause of our problem: #698892: Cron not running every hour
I have set my Poormanscron to run every hour. Today, when I checked the available updates page it showed that hadn't run for 9 hours! Weather icon showed night and it was 13:45! So I run manual check and weather icon updated and displayed correctly.
Comment #13
axel pressbutton commentedHi klonos,
I have a system cron set to run every 15 minutes and still get the issue.
For example - I've just looked now and am seeing the night-broken-light-rain.png image - the weather is certainly correct but the time is currently 15:30
Comment #14
Katrina B commentedI'm having the same problem, especially in the afternoon -- it may be 3 p.m. where I live (which is the time zone set for the site), but I'm getting nighttime images in the Yahoo Weather block.
Comment #15
Pedro Lozano commentedFixed and commited. Here is the patch.
A new release will be created when other issues are solved.
Thanks everyone for the feedback.
Comment #16
axel pressbutton commentedFantastic, many thanks for that Pedro!!!
I'll implement the patch this evening and keep and eye on things :D
Comment #17
klonosI've applied the patch but it didn't seem to fix things. Perhaps something I've done wrong.
I've just now downloaded latest dev and installed it. Will report back if it is ok in 1-2 days because I need to test it and see.
Comment #18
klonosWell, I did install the latest 1.3 version and it seems I need to refresh my page 3 times before the correct weather is picked up. What's up with that? Browser caching issue? I don't thing so because once I refresh 3 times say in firefox and the current weather is displayed correctly, then if I refresh in IE only once it displays there correctly as well. The same if I do it in reverse order (3 refreshes in IE and then firefox).
Any ideas.
Comment #19
Katrina B commentedI changed over from Poormanscron to Elysia Cron, which I set up to have the cron for the Yahoo Weather module running every ten minutes ... and I upgraded to the latest version of Yahoo Weather. I'm still getting night images during the day and day images at night.
Comment #20
Pedro Lozano commented@Katrina B,
can you check if the day/nigh displayed in the Yahoo website is different from the one displayed by the module?
Comment #21
Katrina B commentedOkay, it's currently 1:20 a.m. ... the middle of the night. The Yahoo Weather module on my site is showing a daytime image with a light blue background. If I go to weather.yahoo.com and put in the same zip code as the one used for my site, I get a weather image with a gray background (which I'm guessing indicates night?).
Comment #22
axel pressbutton commentedI've just checked mine and am running the latest version of the module...
it is 9:15 PM GMT here and I'm seeing day-overcast-fog.png
Current condition on Yahoo = Haze (reported time = Current conditions as of 8:50 PM GMT)
Current condition on my site = Haze
Thanks again for any help
Comment #23
klonosThis question is for all the people that are still having issues even with the latest version (after patches have been merged).
Does refreshing the page 2-3 of times also refresh the weather in current (correct) conditions?
Comment #24
Katrina B commentedEven if refreshing 2-3 times finally resulted in the correct weather image, that wouldn't be a satisfactory solution for my site. I'm designing a site for a local newspaper, which will end up with thousands of end users. If the first thing an end user sees on the weather module is the wrong info, is he/she going to know to refresh 2-3 times to get the correct info? No. I need the info and the image to be right the first time.
Comment #25
klonosHey Katrina, thank you for replying.
My question wasn't aiming to propose a workaround since I too need to implement this to a live site. In other words I am not suggesting that the issue is resolved by refreshing the page and we should therefore consider this fixed. All I intent to do is to help the developer of this module by giving him some troubleshooting clues on this issue.
In that extent, you answer is not clear. Please test and see if refreshing actually updates your block with the correct weather info. Does it?
Others with the same problem should also test and reply if the same happens to them with refreshing a couple of times. Lets help Pedro figure this out by testing and reporting back. Thank you all in advance.
Comment #26
whytewolf commentedthe issue looks like who ever wrote the module does not know the difference between zip code and WOEID
the reason you are getting night is because it asks for the zip code, but yahoo is expecting WOEID, most US based zip codes correspond to european WOEID numbers.
Comment #27
axel pressbutton commentedI've just looked again at my site and it was still showing the same daytime image as before...
My system cron has been successfully running every 15 minutes BUT as soon as I run a manual cron the image updated to a night image.
Something is also not right with the temps - My site is showing current temps as;
Current = 1C
Feels like = -5C
Yahoo is showing;
Current = 1C
Feels like = 1C
Wind directions are also not correct. My site shows N 27.36 km/h, Yahoo shows NNE 27.36 km/h
See #8 for my location details
Comment #28
Katrina B commentedI have a tech lead assigned to my newspaper website project who is pretty good at digging into Drupal modules and looking through the code; he's been trying to help me fix the Yahoo Weather module.
He reported today that what the Yahoo weather module needs is NOT the zip code but the WOEID for the city in question; apparently, this is set incorrectly in the module itself.
Comment #29
axel pressbutton commentedHi whytewolf...
Which version of the module are you using? I could well be wrong, but I thought the module asks for the 'country code' which is then possibly just stored in the "zip_code" field of the "yahoo_weather_forecast_blocks" table.
This is then inserted as w=$code in the URL
line 521 - $url = "http://weather.yahooapis.com/forecastrss?w=$code&u=$units";
I've just tried the above url c/w my code and get the correct results (although redirected to the following page once processed);
feed://weather.yahooapis.com/forecastrss?w=12056&u=c
Hopefully I read things right. If not, could somebody please correct me :)
Thanks
Comment #30
axel pressbutton commentedHi Katrina B
Thanks for that. I'm still a bit confused though as to why my system cron appeared to be doing nothing whereas a manual cron run via admin/reports/status at least triggered an update or sorts.
Comment #31
whytewolf commentedI'm running the latest release.
and it sounds like there maybe two different issues then.
for the url you gave, the location is showing as Bath, GB which i hope is correct for your location.
for me when i put in the WOEID [not really a country code but a different number supplied by yahoo]
everything corrected its self.
i still have yet to see it not work, but more monitoring may be required.
Comment #32
whytewolf commentedreally couldn't tell you why running the crons differently like that gave different results, are you running the normal cron that comes with drupal, or trying something like poormanscron or Elysia?
Comment #33
axel pressbutton commentedThanks for the fast replies whytewolf.
I'm running Drupal's cron via the server every 15 minutes with;
Yes, Bath (GB) is correct :)
* Changing the version to 6.x-1.3 as it's still appears to be an issue with the current release.
Comment #34
Katrina B commentedOur tech lead updated the blocks I'd created with the correct WOEID. The blocks looked correct at first; now they're wrong again. It's 10 p.m. ... and I'm getting daytime images.
The info matches what's on Yahoo Weather, so the location is set correctly; it's the images that aren't matching the time of day.
I have Elysia Cron running the cron for Yahoo Weather every ten minutes.
Comment #35
Pedro Lozano commented@KatrinaB and anyone still having issues,
the block displays the sunrise/sunset times, is the current time between these times?
As for the zipcode/woeid issue, sure the initial developer thought the field should be a zipcode, but I already commented above that it was an error and you don't have to enter the zipcode, it's documented in the README.txt and in the field description, I changed the field label in the last release to 'Yahoo code', I may have leave the the zipcode word in some places and that will be fixed in the next release, but it should be clear enough now that you don't have to enter a zipcode in the config.
Comment #36
whytewolf commentedi found the issue, kind of.
strtotime is returning the wrong time with the yahoo formatted date.
when it was 7:44am it was returning 4:44am
I know it's between the strtotime and the later date on that returned time, cause it is correct for the yahoo time in the database.
possible difference in php versions? the server this is happening on here is running php 5.2.8
this could also be a timezone difference issue.
the timezone the main server is set for is PST, but the timezone for the site is EST. allowing for a 3 hour difference.
btw, Katrina, I am that tech you keep mentioning.
Comment #37
whytewolf commenteda work around right now that i am using is instead of parsing the yahoo time through strtotime then dumping it to date, is to just exploded it and grab the 4th and 5th objects [4th being time and 5th being am/pm]
Comment #38
klonos@ Pedro: I had only a 'mini' version of the block configured (only weather and temperature). I enabled sunrise/sunset as well now and I'll monitor it for a couple of days. Let me test and report back.
Do you think this might be the root of evil? I mean not having sunrise/sunset enabled in the block's display.
@ whytewolf: this workaround of yours... which line(s) of which file(s) did you alter and to what?
Comment #39
whytewolf commented@klonos
at around 417 is $date_location = strtotime($weather_info['data']['condition']['date']);
so commented that out. and commented out
$date_loc_str = date('h:i', $date_location);
$date_loc_ampm = date('a', $date_location);
then added
$date_location = explode(' ',$weather_info['data']['condition']['date']);
$date_loc_str = $date_location[4];
$date_loc_ampm = $date_location[5];
if (strlen($date_loc_str) < 5) {
$date_loc_str= '0' . $date_loc_str;
}
personally i think it's ugly and really dependent on yahoo not changing it's time format. but it works for now till a better solution can be found.
Comment #40
axel pressbutton commented@Pedro
My issues are issues within the expected sunrise/sunset times i.e. i will see day images long after sunset and vice versa
@whytewolf
Thanks for the patch details, I'll give it a try over the next couple of days
Comment #41
klonosThank you whytewolf, I think I am going to help Pedro troubleshoot this a bit further before I try your hack. So I am going to test a few days by monitoring sunrise/sunset hours. After that, I will try your workaround and report back.
Comment #42
klonosPedro, I think this is far from 'fixed', so I am changing this back to 'active'. You had it changed to 'fixed' soon as you committed the patch, but I think you should have waited for some positive feedback first.
I am really this close from giving up on this and trying whytewolf's hack. This is what I've noticed so far:
- Yahoo uses EET to display information. I am not sure if it takes daylight saving under consideration, so this could be UTC+2 or UTC+3.
- Even so, In the yahoo website, it still shows daytime for my location when it is passed 1 to 1 and almost a half of an hour after sunset.
- The same as above with sunrise. The sun is up for about 1h to 1h 30m and it shows nighttime. So I am guessing yahoo's clock is almost 1h 30m slow.
- In both cases and once yahoo.com displays the correct day/night information, I still need to refresh 2-3 times to get my site to reflect this info.
So, Pedro please let me know if you want me to try anything else to help you troubleshoot this before I try the workaround.
Comment #43
Pedro Lozano commentedOk, it's not fixed but it is less critical. Before the commit, the wrong images were displayed anytime in the day, now it's limited to near sunrise/sunset hours.
The commited version fixed changes in the yahoo api structure and programming mistakes by the original developer. Now it's a more subtle and elusive problem and it's surely related to that wrong time reported by yahoo problem that you describe.
I'll try to fix it when I got some time. If anyone has a fix you are welcome to submit it.
Comment #44
klonosYes I agree. So the way I see it, there are two sub-issues still standing (for me at least).
1. I still need to refresh the page 2-3 times for the weather block to actually refresh the info displayed. I do not know how to help troubleshoot this one, so I'll have to wait till someone figures this out. I'm more than happy to test patches though ;)
2. There seems to be some time difference between the actual local time and what yahoo seems to believe it is. Further investigation on this shows that the time difference is actually closer to 2h, so I guess it has to do with UTC+2 or something. I cannot tell for sure though.
Just a thought here and in order to troubleshoot this: how can I 'manually' add 2h in the module's sunrise and sunset variables once their values are retrieved from yahoo?
Finally, Pablo I would like to say thank you for all your time and effort spent on this project. I recognize this and if I sounded a bit hard in my previous post it wasn't because of you, but because of the complexity of this issue.
Comment #45
axel pressbutton commentedKlonos - re. your point 1. - I don't suppose you have Block Caching enabled in /admin/settings/performance? I'm wondering if this could be the cause of this.
re. the time being reported by Yahoo, I noticed that they sometimes don't even show regular updates in the early evening i.e it'll say something like "Current conditions as of 6:50 PM GMT"...could this also throw a spanner in the works if it's not updated for a couple of hours?
Comment #46
klonos@Axel: no, I have all cache disabled for the whole site and I think I'll enable it only once it is finished and if it is absolutely necessary. This because I see it causing many issues with different modules. And when I say 'no', it is not just to give a fast answer. I did actually double check and no caching options are set to 'enabled'.
As for the 'Current conditions as of...' thing, that is a good point there but I have no clue as to how to troubleshoot it. Sorry. Do you have anything in mind I could try?
Does the other suggestion for troubleshooting make any sense to you (or anyone else)? I mean...
The module retrieves the sunrise and sunset times for the current date once it is past midnight (my guess). Then, it checks to see if current time is before or after these times and sets the 'day-'/'night-' prefix of the image to display accordingly. So, if there is some kind of 'offset' in the day/night time, I could add a certain amount to the variable that holds these values (sunrise and sunset I mean) and see if that sorts things out. How could I do that if this actually does make any sense? How can I add 1 or 2 hours to the sunrise and sunset values after they are retrieved?
PS: @Pedro: I am really sorry for calling you 'Pablo' in my previous post. I really am ashamed. Honestly, I am sorry.
Comment #47
whytewolf commentedklonos you are mostly correct, however the module does not use the servers time for determining what time it is. it uses the time returned by yahoo. using this $date_location = strtotime($weather_info['data']['condition']['date']);
look towards the beginning of the template_preprocess_yahoo_weather_forecast_content function
Comment #48
klonosOk then, how do I add +1 or +2 to the time fetched from yahoo?
Comment #49
whytewolf commentedwell, if that is really what you want to do, you could just add this right under it
$date_location = strtotime('+2 hours',$date_function);tho really thats just another hack like that one i posted earlier. the real problem is not being addressed.
Comment #50
klonosThanx, I will try this one and see how it goes.
I know this is a hack, but I am almost desperately looking for a workaround to remedy this issue (until an actual fix comes up).
Comment #51
klonosThank you whytewolf, I think that my troubleshooting is coming to an end now. Soon I'll be posting my findings.
It just stroke though... In my final site there'll only be the weather image, temperature and current condition (no forecast, since I am going for a 'mini' version: #669588: display weather images as a set of overlaid images). For troubleshooting's sake I've enabled sunrise/sunset as well, but now I realize I'm going to have to display the time fetched from yahoo in order to easily see what it the 'offset' between the yahoo-fetched time and the actual location time.
Any ideas what should be added to the yahoo-weather-forecast-content.tpl.php file? I've tried:
<?php print $date_loc_str ?>...but it doesn't output anything on the block. Perhaps something I need to add/change in yahoo_weather_forecast.module first?
Comment #52
Pedro Lozano commentedklonos, whytewolf and anyone having problems, could you tell me your location and the code you are using so i can do some debugging using it? If you don't want to post it here you can send it to me using my contact form.
Comment #53
klonos@Pedro: PM'ed you with the information you asked. Let me know if there is anything else you need.
Comment #54
Pedro Lozano commentedThanks klonos,
it seems that the time returned by the Yahoo api is the time when the weather data was last updated not the current local time. Depending on the city the weather info is updated more or less frequently. For example, for Barcelona the weather is updated every 30 minutes so the time reported by yahoo may be delayed up to that amount.
For other cities the time between weather updates seems to be longer (up to several hours). That's why the module prints the delayed conditions, including the day/time image. In the Yahoo's website you can read "Current conditions as of ...", which is the time the module thinks it is.
The first solution that comes to my mind is to add a timezone selector on each block and to make the conversion using the server time.
Comment #55
klonosThat was exactly my thought as to where the root of evil might be as well. That's why I needed to display the time that yahoo thinks is current for my location + a way to subtract/add hours to this time as a hack.
I think the drop-down selector will definitely solve the issue for people that use locations that aren't updated in a more regular basis. Lets hope that it will not cause any issues to the rest of the people that have it working as expected. Just in case such an issue comes up, I think we should still retain the way sunrise/sunset is calculated now and have the timezone based as an alternative/troubleshooting way (I am thinking a 'Use timezone + server time to calculate sunrise/sunset' checkbox that would enable the drop-down).
Other than that... I can't wait to see something implemented and I am ready to test any patch.
Comment #56
klonosJust downloaded latest March 03, 2010 dev and noticed among others that you switched from
h:itog:i. You also use$sunrise[0] = '0'. $sunrise[0];. My guess is in order to add a leading zero(?). Doesn't this need to be done for $sunset as well?Wouldn't it be easier instead of checking time + am/pm to use
H:iorG:i?Thanks for giving this issue some love ;)
Comment #57
klonos...sorry, my bad. I checked against a December dev. Still... the use of
H:iorG:iand the addition of:questions apply.
Comment #58
klonos@Pedro:
Any luck with that?
How about my proposal in #57 to use 24h format for sunrise/sunset times (only for easier calculations in the code, not for presentation)?
Comment #59
klonos...ping?
Comment #60
mckramer commented@klonos
re: #57
That comparison is only used to decide if it is day or night. Adding the "0" allows to compare the two strings. It does seem intuitive that the sunset should be edited as well. I have added it in the version I am editing/improving.
The time is taken from the "condition" tag and the sunrise/sunset is take from the "astronomy" tag. See below:
Therefore, the code adds the leading "0" and uses
h:iand am/pm. I did not have any luck trying to format the sunrise time asH:i, which would allow to compare without having to add the "0" and use the am/pm.The version I have been working on adds a lot more options to the module, including being able to hide the images (as requested in another issue). The way I am working around it is to add the "build time" (or the time when the last data is from) and add it to the block. That way the delayed information is apparent. The ttl on the city I am using is 60 minutes, so there will always be a delay. Unless you wanted to decide the time of day based on the server time.