The instructions state: “There are 365 possible birthdays (no leap years),” and “Your implementation must follow these assumptions.”
At least one test suite (Go’s) checks that randomBirthdates never returns a date in a leap year (not just the 29th of February, but any day in a leap year). This implies the the “assumption” is that we avoid leap years in this problem. There is also a note emphasizing the difference between a birthdate (includes year) and birthday (does not include year).
If we actually avoid leap years, an intuitive representation of a “date without a year” could be the day of the year. On the other hand, if we allow leap years, this representation wouldn’t match our intuition (March 1st could be the 60th or 61st day of the year). It would still be coherent to talk about two people being born on the 60th day of the year, but the problem shifts to finding matches for people born on December 31st of a leap year.
Even though the instructions say “no leap years” and the tests even enforce that for the data we generate, the test data itself is full of dates from leap years. Most problematically from the perspective above is the case "two birthdates with same month and day, but different year", ["1999-10-23", "1988-10-23"], where 1988 was a leap year but 1999 was not, and its using a month after February.
My suggestion would be to avoid leap years in the test data, at the very least in that one case. Alternatively, instead of making the test data conform to the requirement, the requirement can be loosened up in the validation, allowing dates in leap years but only rejecting February 29ths.
These tests are independent. One asks you to generate random (non-leap-year) dates. The other asks you to perform analysis of specific dates. The non-leap-year requirement shouldn’t matter to the analysis task so it shouldn’t matter if those inputs are or are not leap-year dates. In fact, testing that they can handle any year could be considered a good thing.
I saw that the test data comes from the spec so tagged this thread with problem-spec, but I added the Go tag because I wasn’t sure if any other languages validate the generated data against a requirement that I don’t see explicitly defined in the spec.
That’s the core issue here, the statement about leap years isn’t specific to the description of the generation task. It’s in an exercise-wide warning. How the generation task fits into this exercise is as input to the analysis task. If our analysis function is capable of handling dates in leap years, then what is the problem with generating such dates? If the warning instead meant “pretend there is no such thing as leap days,” then it would still be fine to generate dates in leap years, as long as we avoid February 29th.
Thank you for linking to that exercise improvement guide. I can see from that that you would be very wary of updating any of the spec after it is published.
Yeah, that statement does seem a bit misleading like that…
I can see the value in making that no-leap-year statement scoped to the generate step and/or updating the test data.
Changes need to be considered carefully. That said, updating the years used in the test data should not impact existing solutions in any way so that should be a pretty safe change.