Description: ------------ It's apparently not uncommon for station TAFs to include the TAF for another station - eg: "EGXT 021459Z 021518 29015KT 9999 SCT030CB= TAF LKCV 021400Z 021524 22014KT CAVOK TEMPO 1517 24020KT" (Hehe, probably best not to ask why a UK RAF station TAF includes the TAF for one in the Czech Republic!). I've seen this format on quite a few other stations. The above parses as: Array ( [0] => EGXT [1] => 2008/10/02 14:59 TAF AMD EGXT 021459Z 021518 29015KT 9999 SCT030CB= TAF LKCV 021400Z 021524 22014KT CAVOK TEMPO 1517 24020KT [2] => 02/10/2008 14:59 [3] => 2008/10/02 14:59 [4] => 021518 [5] => 02/10/2008 15:00 [6] => 02/10/2008 18:00 [7] => Array ( [15:00] => Array ( [wind] => 14 [windDegrees] => 220 [windDirection] => SW [visQualifier] => BEYOND [visibility] => 9.99 [clouds] => Array ( [0] => Array ( [amount] => Clear below [height] => 5000 ) ) [condition] => no significant weather [fmc] => Array ( [0] => Array ( [type] => TEMPO [from] => 15:00 [to] => 17:00 [wind] => 20 [windDegrees] => 240 [windDirection] => WSW ) ) ) ) [8] => SCT030CB= LKCV ) Expected result: ---------------- Parsing should terminate at the "=", which normally indicates "break".

Hey Robin, for those of us who don't know where exactly to stick a TAF, is there any chance of turning this into an executable test script (or at least pointing me in the vaguely correct part of the API so I can write one?)

Hi Daniel, not sure what you're asking here. Assuming you're familiar with the Services_Weather package, what I'm doing is building a modified version of .../examples/metar-extensive.php in the package docs into a web page for use by myself and fellow airplane drivers. That immediately threw up the reported bug, plus several others subsequently. The above report assumes a fairly in-depth knowledge of aviation TAFs and METARs, which I presume the original author has. Otherwise I appreciate it's going to be pretty impenetrable! If you're asking what TAFs and METARs are and what you can do with them I suggest we take that off here - feel free to email me privately. (Is that correct protocol? I don't frequent this place much). I have actually found a simple and effective fix for the above bug, and am presently working on a bunch of others. At the moment it's an unholy mess (and turning into a fairly extensive re-write of the relevant code!), eventually I'll tidy it up and submit a patch if people are interested.

This bug has been fixed in CVS. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Has been fixed by looking for a "=" and dropping everything behind it. Thanks for the report!

The following patch has been added/updated: Patch Name: metarpatch.txt URL: patch metarpatch.txt

The following patch has been added/updated: Patch Name: unitTest URL: patch unitTest

The fix for this bug is incorrect. Your performing a strpos() operation on $data - which is an array, not a string. Patch and updated unit test attached.

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better. Thanks for your patience and the unit test... should be really closed now.