My post immediately before yours deals with this issue - well it does for me.
I had not noticed that the two forecasts were the same - don't believe they were yesterday but they sure seem to be today - just checked 6 from different parts of the country and all have Wednesday and Tonight the same (yes its 4pm Wednesday here).
So perhaps you can forget the code line below that changes Wednesday into Today and just change the test for time from < 6 to , < 12.
Since the change to JSON encoding that Ken's ver 2.04 script handles, the daytime forecast is always there in the file that is downloaded from WU.
However it changes from Today to the name of the day some time in the afternoon.
If you apply the two script changes I detail in my last post, Today will always be Today, and the Today will disappear at 18:00 (that is what the < 6 test does - you can fiddle with the number to suit yourself).
Make a copy of your WU-foreast.php script to another name for safety, and edit the one you have with the two changes and the issue should go away.
If it doesn't work then just put the original back.
The mod you made is very English specific and may not work as anticipated when a non-English WU forecast is selected. Since the WU-forecast script is available for both standalone and Saratoga template use, I had to rely on WU doing all the translation activity for the day names/text. So.. if you're only using English, BCJKiwi's mod would work fine -- for non-English, it likely won't work as expected due to non-English word for 'Today'.
I've not quite figured out when WU updates the forecast routinely and whether or not it is 'time-zone' aware (likely not), but I'm browsing the massive JavaScripts that do the WU page generation from the JSON data to see if there's an underlying algorithm for proper display of Today/Tonight. Meanwhile, the default script just displays what the first entry is in the JSON.
Also, running a page with WU-forecast on it with ?debug=y shows (in the view-source) a bit of analysis about the number of hours/times in the hourly forecast for the first entry in the JSON -- that may help pick the number of hours to use to skip the first entry.
Best regards,
Ken