Aww, man, this expiry date doesn't write the months with letters! I can't tell if it's expiring on March 10th or October 3rd... Wait, no, never mind, the year says 2012. (alley-oops half-used brick of cheese into the trash can like a pro)
So let's suppose for a moment that you're too busy to try to reason out when this jar of marinara is supposed to expire. You just want the Cliff Notes version: how likely is it that it's past due? Let's write some code!
You know that the manufacturers print the date as an ordered triple of integers, in one of three formats:
YEAR MONTH DAY MONTH DAY YEAR DAY MONTH YEAR
And you know that some dates can only be interpreted in one or two ways, not all three: the 55 in
55-11-5 has to be a year, meaning this particular box of Twinkies expired November 5th, 1955. The year is sometimes given in four digits and not two, which can rule out some options. When it's two digits, though, 50..99 means 1950..1999 and 0..49 means 2000..2049.
Your job is to write a program or function that takes an array of integers which is a valid date in at least one of the interpretations above, and outputs a percent chance it is still good. The percent chance is simply the percentage of valid interpretations of the date that are on or later than today's date.
The array of integers will be your language's
[Int] type of length three if it is an argument to a function, and given as either dash-, slash-, or space-separated (you get to pick) integers if used as input on STDIN to a full program.*
"Today's date" can be today's actual date, as obtained through a date function, or the date given in an extra argument to function or extra paramater in STDIN. It may be in Unix epoch seconds, another year-month-day triple entered in one of the three ways above, or another more convenient fashion.
Let's have some examples! The expiry date input will be in the dash-separated style, and assume for the examples below that today's date is July 5th, 2006.
14-12-14- Both valid interpretations for this (DMY and YMD) are equivalent, December 14, 2014. The output is 100 because this product is definitely still good.
8-2-2006- The last number is a year, for sure, since it has four digits. This could be either February 8th (expired) or August 2nd (still good). The output is 50.
6-7-5- This could be anything! The "July 5th, 2006" interpretation is still good (for one day only), but the remaining two are both in 2005 and should be tossed as quickly as possible. The output is 33.
6-5-7- Here, two out of three interpretations are safe. You can round your decimal up or down, so 66 or 67 are both okay.
12-31-99- Okay, this one is unambiguously from the turn of the century (years from 50 to 99 are 19XX, and 31 can't possibly be a month). A big fat 0, and you really should clean out your fridge more often.
You can safely assume that any input which does not meet the standards above is not privy to the output rules above.
No web requests or standard loopholes. Date handling libraries are allowed. This is code golf: may the shortest program win.
* If you are using brainfuck or some similarly datatype-handicapped language, you can assume the ASCII values of the first three characters in input are the integers for the date. This excludes the four-digit year logic, sure, but I think we would be too astounded by seeing a solution to this in Brainfuck to slight you for it.