looks good to me.

Good kata overall. My only beef is that the provided query (that needs to be reworked) uses old-style JOIN syntax and orders by column index rather than name.

Looking at expected and actual results, it seems I'm getting the right results. However, I keep failing one test:

Test Failed
@@,date      ,count,percent_growth
  ,2017-08-01,65   ,NULL
→ ,2017-09-01,335  ,␣415.4%→415.4%
→ ,2017-10-01,357  ,␣␣␣6.6%→6.6%
→ ,2017-11-01,289  ,␣-19.0%→-19.0%
→ ,2017-12-01,339  ,␣␣17.3%→17.3%
→ ,2018-01-01,314  ,␣␣-7.4%→-7.4%
→ ,2018-02-01,297  ,␣␣-5.4%→-5.4%
→ ,2018-03-01,349  ,␣␣17.5%→17.5%
→ ,2018-04-01,259  ,␣-25.8%→-25.8%
→ ,2018-05-01,342  ,␣␣32.0%→32.0%
→ ,2018-06-01,323  ,␣␣-5.6%→-5.6%
→ ,2018-07-01,315  ,␣␣-2.5%→-2.5%
→ ,2018-08-01,306  ,␣␣-2.9%→-2.9%

It seems there's either characters missing I need to add at the beginning of the %, or extra characters I need to take away. Am I missing something?

As others have said, this kata has very poorly written instructions. I initialy just returned the liters, since that's what the instructions seemed to ask for. Only by looking at the test cases did I realize that the other columns were needed. Also, the instructions use the British spelling (litre), while the tests expect the American spelling (liter).

Perhaps I'm missing something, but I can't seem to get the correct end results. Based on the way I'm reading the instructions, we're supposed to find the maximum number of overlapping entries by date, right? So if Entry ID 1 started on 2018-05-01 and ended on 2018-05-05, then the following entries would be considered overlapping:

• An entry that started on 2018-05-02 and ended on 2018-05-06, because the start is between the first entry's start and end.
• An entry that started on 2018-04-28 and ended on 2018-05-02, because the end is between the first entry's start and end.

However, the following entries would not be considered overlapping:

• An entry that started on 2018-04-28 and ended on 2018-04-29, because the start and end are both < the first entry's start date.
• An entry that started on 2018-05-06 and ended on 2018-05-07, because the start and end are both > the first entry's end date.

Please let me know if I'm misunderstanding the problem.

Thanks!

I think the database design is a bit wonky. I think a better design might be separate tables for elements and Multiplers. Something like Elements(element_id, element_name and Multipliers(attacking_element, defending_element, multiplier). It was a bit unclear to me at first that the Multipliers table was only for pokemon attacking grass types (which works for this challenge, but, again, I don't think is a very well-designed structure).

It might just be me, but it seems the description is unclear in how the encoding is to be done. When I first read the description, I thought the shift would only increase by one for each character to be encoded. For example, encode('A Day', initial_shift=1) -> 'B Fdc'. However, based on the test data, it seems that the shift increases for each position in the message, regardless if the character is actually to be encoded. So non-encoded characters (i.e. punctuation) are included in the count. So encode('A Day', initial_shift=1) -> 'B Ged'. I feel like this might have been made a bit more clear in the description.