Description
Summary
We fixed the timezone issue (#119) in #120. I suspect this fix by chance made the 'not-so-forecast' problem fixed by #64 gone1 you describe starting right here as well:
... and it may be safe for us to remove this block of code.
1in that, the problem don't exist anymore.
Details
Before the fix, in this line we were comparing $today = new DateTime(), which was the current time in current timezone and was always correct, with $date = new \DateTime(isset($time['day']) ? $time['day'] : $time['to']), which was the formatted UTC date parsed in current timezone and could be wrong.
In the environment where our timezone is ahead of UTC (like Asia/Tokyo), that would cause $date to fall way behind the intended time (-9 hours if Asia/Tokyo,) which will, when the time difference between UTC and our timezone is big enough, cause $date < $today.
When I was poking around #119 (trying different timezones etc.,) this behavior looked really like a timezone related issue because what was being omitted have changed depending on the zones. However, the time zone issue has been fixed in v2.3.0. So I started examining the response XML, and I still haven't found any forecast whose $date < $today. I'll keep an eye on those XMLs for a little while (to minimize the fear of the existence of 'not-so-forecasts,') but I think we can safely delete that if statement. Let me know if you did experience the 'not-so-forecast' with v2.3.0 :)