Puzzling Forecasts

Tweet

In the same vein as this, here’s a real world puzzle that might serve as a nice (or annoying) interview question – relates to something I had to deal with at work today.

There are a number of types of aviation weather bulletins, used worldwide and often critical to the operations of airlines etc. Many were designed prior to the dawn of XML and tend to have “interesting” formats – fun to understand, even more fun to parse. I imagine the designs were driven by system limitations – the days where a few bytes here or there really mattered – as well as the unique way the airline industry sees the world – something like RFC 3339 dates would be pure wasteful luxury.

For example METAR reports describe the current weather conditions at an airport while TAF is weather forecast for an airport.

Now a given TAF forecast will be valid for a maximum of 24 hours and a minimum of at least one hour (in practice, not normally less than six hours I believe). By “valid” in this context, I mean the time period for which the information contained in the forecast can be regarded as accurate.

You can look at TAFs online here – try entering the code EDDF (Frankfurt airport in Germany) for example – these are the longer TAF forecasts – valid up to 24 hours. There are also TAF forecasts for shorter time periods (e.g. 9 or 12 hours) here.

Looking at a short forecast for Frankfurt (EDDF) issued today at 18:00 UTC, we have;

TAF EDDF 061800Z 061904 19012KT 9999
SCT015 BKN030 TEMPO 2204 RA BKN012

The number I highlighted – 061904 – describes the validity of the forecast (I believe the first two digits are sometimes omitted but for this discussion we’ll ignore that and say it’s always six digits).

Imagine you are building a web app to retrieve forecasts. Pilots enter an airport code like ‘EDDF’ and this six digit code into a form.

On receiving a request, you first need to validate the six digit code that the pilot enters then, after that, extract two dates from it to perform a SELECT with.

Here are some “unit tests” for the validation function;

  • input: 150024 – function returns ‘valid’
  • input: 340312 – function returns ‘invalid’
  • input: 070315 – function returns ‘valid’
  • input: 081221 – function returns ‘valid’
  • input: 000305 – function returns ‘invalid’
  • input: 070606 – function returns ‘valid’

Write a function to validate the six digit code.

Write another function (no tests available this time) that returns that start date / time and end date / time for the validity period.

On a side note – just for interest: there are Open Source TAF decoders out there – PHP Weather supports it I believe as does Geo::TAF. And Geo::METAR is the work of Jeremy Zawodny – I guess here’s why. Anyway – don’t let that distract you ;)

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Fenrir2

    Shouldn’t the first one be invalid or 150000?

  • dusoft

    module support for METAR decoding is also part of Absolut Engine CMS / PHP framework

  • http://www.errewf.it RaS!

    Following the METAR standards, that six digits explain the datetime of METAR report. In deep, the first two digits shows the day and the last 4 means the time in zulu, so a string like: 081633Z means the Metar has been created the day 08 of current month at 16:33Z