meetup: `description.md` doesn't match up with canonical-data

[m-dango]

According to the exercise description, the expected input should be a description of the date:

you will take a description of a meetup date, and return the actual meetup date.
For example, if given "The first Monday of January 2017", the correct meetup date is 2017/1/2.

It looks like things may have gotten mixed up in PR #1050.

[ErikSchierboom]

I don't see how things have gotten mixed up. With the merged PR, the input looks like this:

"input": {
  "year": 2017,
  "month": 1,
  "week": "first",
  "dayofweek": "Monday"
}

To me, this matches exactly the example you quote above, which has four parts: "The first Monday of January 2017" (emphasis on different parts).

[m-dango]

From what I gather from description.md, the key description should be the input.

EDIT: I recall a similar discussion was had previously in PR #1006 (comment)

[ErikSchierboom]

@mienaikage Aha, but I only tried to conform to the new "input" format, and not update the existing format.

I'm not opposed to doing what was suggested in #1006 and converting the input to a sentence, but that should be a new PR IMHO.

[rpottsoh]

It appears to me that the canonical data has not agreed with the description for quite some time, I think #1050 was correct as its purpose was not to bring the test data and description into agreement.

The canonical data and/or the description should be updated so they agree with each other (as has been previously discussed). It doesn't matter to me which file changes or if they both change in order to reach common ground.

[ErikSchierboom]

@mienaikage Would you be interested in creating a PR for this? If so, you might want to also look at #978, which also aims to improve the meetup canonical data by introducing some grouping.

[m-dango]

I'll create a new PR shortly.

[ErikSchierboom]

Great!

[m-dango]

Apologies for the delay, I'm still working on rewriting canonical-data.json.

[petertseng]

A small request to the person who do this: Decide and explain whether to recommend that implementing language tracks must also use the full string as input (adding the parsing aspect to the required implementation for this exercise) or if instead they might feel free to continue using the structured input (in which case the problem is about turning the structured specification into a date)

[petertseng]

If the person who makes that decision needs to refer back to history, that person might benefit from starting with exercism/exercism@1e87b00 the original