Even though forecast days is set over 4 days, forecasts are reported only up to 3 days in Forecast tab of Weather Report window. Build & Platform: Build 2013-01-19 on Arch Linux
Could be a problem with the new forecast code, it might still need improvement. Do other locations show the same problem? Please provide location (search term or better lat/lon) for which this happens; your local timezone might be useful too.
And another important thing: Are location and local timezones identical or do they differ? Anything strange with the times (interval start, end, and calculated for) provided by the tooltips in the forecast cells?
Timezone is JST (+900) I conformed that the following locations shows same problem: *Tokyo, Japan lat=35.680971;lon=139.767439;msl=15 TZ is identical Times seems to be no problem (just JST) *Washington D.C., USA lat=38.895115;lon=-77.036372;msl=6 TZ is differ Times seems to be no probem (All of them shows as JST) *Sydney, Australia lat=-33.854816;lon=151.216454;msl=23 TZ is differ Times seems to be no probem (All of them shows as JST) *Oslo, Norway lat=59.913269;lon=10.739111;msl=23 TZ is differ Times seems to be no probem (All of them shows as JST)
With my local timezone I see no problems for these locations. So there has to be something wrong with the code. I will try to reproduce this using your local timezone, but do not know yet how to easily change the timezone of my system here. It will take some time. If you could attach debugging output as described in the readme, that would probably help too. Just to be sure and exclude misunderstandings because of different language: You mean you set it to 10 days, and there are only forecasts for 3 days, right? The cells for the rest of the days is just empty.
Created attachment 4865 panel's log Attached is panel's log. Location is London and tried to change the location but not changed.
Created attachment 4866 Screen shot of Forecast tab > Just to be sure and exclude misunderstandings because of different language: > You mean you set it to 10 days, and there are only forecasts for 3 days, right? > The cells for the rest of the days is just empty. Yes. I set 5 days. Please see attached.
Created attachment 4867 increase-search-interval.patch Thanks, I will examine the debug output later. I've looked a bit at the code, here is a quick attempt to fix it, but it will need more verification. Could you try the patch? Does it change anything?
Looking at the debug output, I think the problem is related to the hours chosen for the daytimes (9, 15, 21, 3). With your local timezone, these times are exactly at the start or end of the intervals provided by met.no. I'm not sure the previous patch would help. The previous version 0.8.2 did not have this problem but then it might not have shown the correct values at all. I'll think about how to best solve this and attach a better patch. This will take a while, as it's a bit tricky to make those intervals fit into the morning/afternoon/evening/night scheme. However, your information was very valuable and will help me a lot with that timezone stuff in general. What's more, it revealed I've found yet another bug to fix, because for Oslo, cloud data and relative humidity are not provided for all intervals a few days into the future, and that will need to be taken care of too. E.g., dew point cannot be calculated without relative humidity.
Created attachment 4868 change-daytimes.patch For a first test, you could try to apply this patch which decreases the hours for the daytimes by one (e.g. in the morning it tries to calculate values for 8 o'clock instead of 9), thus using the interval from 3-9. An alternative would be to increase them by an hour (e.g. 10 o'clock instead of 9), using the interval from 9-15 - of course that would be a bit late for the morning. While point data like the temperatures would be correct, one needs to take into account data for the interval, which are symbol and precipitations. This way or the other, somehow one needs to distribute the values properly over the day. I'm not sure how far to go with adjusting the daytimes, or if it would be better to let the user make the choice. Please try this patch if you can and report back a) if it improves the situation and b) if the values and times make sense to you.
Created attachment 4870 Shown all days (In reply to comment #9) > a) if it improves the situation and All day's data are shown, please see attached. > b) if the values and times make sense to you. I think those are reasonable.
Thanks for testing. I will try to optimize this so that the best intervals are chosen without the need for more user configurability options. While for your timezone this is solvable rather easily, for users with certain other timezones this could be more tricky because of the GMT<->local timezone shift, so I need to do more testing here.
Created attachment 4892 fix-daytime-forecasts.patch Here is a patch that fixes the problem for all locations and timezones I tried. I hope it works for you. Could you please try this patch too, to verify? Here is an example of one of my tests: 1) Quit panel: xfce4-panel -q 2) Set timezone to another one than that of the local time and start the panel: TZ="Australia/Lord_Howe" xfce4-panel & 3) Search and select for a location in that timezone, e.g. Lord Howe. (I haven't yet thought about the possibility to set the TZ variable. Maybe this approach could work and solve that timezone problem in an easier way than what I had in mind.) This gave me the correct times and forecasts for all days. The interval times for the first three days are usually different from days 4-10 because there are more raw data points available, at least for more prominent locations like cities. Maybe this could be fine-tuned a bit more, but to me the chosen intervals seemed to be quite good already. If you have any recommendations or ideas for improvements, please let me know. If something goes wrong, the plugin should provide quite a lot of debugging output. I will probably reduce this a bit in the final commit.
Created attachment 4896 panel's log on several TZs All day's data are shown. I noticed that interval's transition patterns aren't similar between several TZs. Is it properly? I don't know this is problem or not (I feel it's trifle, though :)). Attached is panel's log of each TZs. --- System wide timezone is "Asia/Tokyo" Forcast days=5 $TZ="Europe/Berlin" Loaction=Berlin, DE Interval is changed between 3rd day's Afternoon (9:00-15:00) and Evening (19:00-01:00) Location=Lord Howe, AU Interval is changed between 3rd day's Morning (4:00-10:00) and Afternoon (13:00-19:00) Locaton=Tokyo, JP Interval is changed between 3rd day's Morning (4:00-10:00) and Afternoon (13:00-19:00) Locatioin=Moscow, RU Interval is changed between 3rd day's Morning (4:00-10:00) and Afternoon (13:00-19:00) $TZ is unset Location=Tokyo All day's intervals are same Location=Berlin All day's intervals are same Location=Moscow All day's intervals are same $TZ="Asia/Tokyo" (same as systemwide) Location=Tokyo All day's intervals are same Locaton=Berlin All day's intervals are same Location=Lord Howe All day's intervals are same $TZ="Australia/Lord_Howe" Location=Lord Howe All day's intervals are same Location=Tokyo All day's intervals are same Location=Berlin Interval is changed between 3rd day's Night (21:00-03:00) and 4th day's Morning (05:00-11:00) Location=Moscow All day's intervals are same $TZ="Europe/Moscow" Location=Moscow All intervals are same Location=Berlin Interval is changed between 3rd day's Evening (15:00-21:00) and Night (22:00-04:00) Location=Tokyo All intervals are same Location=Lord Howe All intervals are same $TZ="America/New_York" Location=New York City, US Interval is changed between 2nd day's Night (22:00-04:00) and 3rd day's Morning (07:00-13:00) Location=Moscow Interval is changed between 2nd day's Night (22:00-04:00) and 3rd day's Morning (07:00-13:00) Location=Berlin Interval is changed between 4rd day's Morning (03:00-09:00) and Afternoon (13:00-19:00) Location=Tokyo Interval is changed between 2nd day's Night (22:00-04:00) and 3rd day's Morning (07:00-13:00) Location=Lord Howe Interval is changed between 2nd day's Night (22:00-04:00) and 3rd day's Morning (07:00-13:00)
(In reply to comment #13) > Created attachment 4896 > panel's log on several TZs Thanks for your extensive tests and data collection. It confirms my observations, so the patch seems safe to use for all people. > All day's data are shown. > I noticed that interval's transition patterns aren't similar between several > TZs. > Is it properly? > I don't know this is problem or not (I feel it's trifle, though :)). Yes, that is because data provided by met.no is not computed to take into account for the UTC-to-local timeshift. They calculate their intervals for 0-6, 6-12, 12-18, 18-24 UTC for all locations, not respecting the timezone difference (I guess that would be quite a lot of work and very complicated too). You can confirm this shift by searching for the location on their website (yr.no) and looking at the results. Where the plugin forecast tab differs from the results of their website is in the times of the intervals for the first three days. That is because the algorithm doesn't choose the intervals 0,6,12,18 UTC but finds the other ones too (3,9,15,21 and maybe more), and takes these if they are 6 hours apart. Such intervals are usually only available for the next three days, as for the rest of the days data gets more sparse. This behaviour can be optimized a bit of course, but the more important thing for now is that it works and provides forecast data for all locations. I have also prepared patches to fix the timezone problems by putting the plugin into the locations' timezone, using the TZ environment variable, which is much simpler than recalculating all dates as I planned to do previously. They essentially do what you did by manually setting TZ before starting the panel, but allow you to auto-detect/set this option via the config dialog. I just need to make sure it works alright and will commit this later. The plugin can then be used for any location you choose, showing the local times at the location. Unfortunately this means a bit more work again for translators, but I find it worth it, and release is still two weeks away.
Fixed in http://git.xfce.org/panel-plugins/xfce4-weather-plugin/commit/?id=96982f5d60998702a510c8bc3d655bf6636552c0 If I find time before release, I will tweak things a bit, otherwise the current solution should be fine too.