I may be having an issue with TAF processing after installing MR2 update beta. I've got a pretty good understanding of how TAFs should be employed...I downloaded current weather:http://forums.avsim.net/user_files/79613.jpgThe only issue I might have with this screen shot is that while the current weather states 2250Z, which should be 23Z, the save dialog is defaulting the filename to 00Z...Made sure that TAF processing was enabled...http://forums.avsim.net/user_files/79617.jpgFire up FS, load a flight using system time which is just seconds after downloading the weather:http://forums.avsim.net/user_files/79615.jpgLoad weather into FS9, and wait for AS2k4 to kick in:http://forums.avsim.net/user_files/79619.jpgDynamic TAF is indicated. Now, even if the time was off by an hour because of DST, the metar should still be used instead of the TAF at this time, since everything is current...?Same thing happened last night. I'm going to test something in an hour or so, maybe tomorrow am...Best,sg

So, I tried starting flights at 21z, 22z, 23z, 00z, 01z, and 02z with "use system time" both enabled and disabled in AS2k4, I always get TAF data...

Hi Scott,I checked at KLEB..Noticed that the TAF elements are a bit different here. There is a very "recent" entry (i.e. right now there is a 0200Z TAF element and recent METAR is 0153Z. Time now is 02:50Z making the 0200Z TAF element most current.It is very rare to see such "short-term" TAF elements, and this is most likely due to improved NOAA/ICAO reporting processes. In any case, it is confusing the AS2004 TAF processor. Ideally the 0200Z TAF should be discarded in condition checking because a valid METAR exists and should override everything. Basically, we need to ignore any TAF element when it is within 30 minutes of the METAR timestamp.I will get working on it right away :) Thanks a bunch for the very quick heads up on this one!-Damian

Thanks for checking - I didn't even think to look at valid times for the TAFs...Best,sg