fixed - updated the description

Email script differ between description and tests:

"(...)Unfortunately, you have selected a bad(...)" (description)

vs.

"(...)Unfortunately you have selected a bad(...)" (test).

It probably should, but I believe that was not the point of your original remark.

Perhaps this issue would benefit from being re-written with appropriate cases. It's a waste of time to work with inconsistent input, as the saying goes - "garbage in, garbage out." In reality, people work with actual data rather than just descriptions of it. When something goes wrong, it's necessary to provide the dataset that caused the issue. I find it amusing that many computer science challenges focus on "corner" cases. In my experience working on production problems, developers don't typically think about "corner" cases; they focus on addressing the specific problem at hand. While there may always be another "corner" case that arises, the sheer number of potential cases is unlimited, so the idea of covering them all is unrealistic.

Maybe the default test should include result validation? :-)

I'm not aware of any errors. Correct solution passes tests just fine.

Which test did fail for you with that 'expected result'?

The default test - the only with the above dataset - doesn't include result validation.

Is something wrong with the simple test?

select * from visits;

id	entry_time	exit_time
1	2019-04-01 00:00:00 +0000	2019-04-03 00:00:00 +0000
2	2019-04-08 00:00:00 +0000	2019-04-09 00:00:00 +0000

The above obviously do not overlap, but the expected result is

when_happened	visits_count
2019-04-01 00:00:00 +0000	2

Very challenging kata, very good thing to learn how to count overlaps. Had to draw a lot of diagrams just visualise what my query is attempting to do.

Sets the name (alias) of result column.

What does "as mod" do?

You're right on all counts! Thanks!

Your interpretation of exit_time description and start=exit is correct.

Wording of exit_time definition was specifically chosen to express interval
openess and covers points 2 and 3 and, by extension, point 1.
I don't believe further extension of specification is needed.

Your solution seems to incorrectly handle case described in p. 2.

I've noticed it sometimes fails two. The other:

rows did not match expected

@@,when_happened ,visits_count

→ ,2021-02-23 23:50:28 +0000→2021-02-24 23:50:28 +0000,20

Btw, hey, Codewars Team! The formatting doesn't seem to work in this comment the same way as in my previous.

At exactly exit time the visit is considered to have already finished.

I interpret it as ends not belonging to the intervals. It then shouldn't matter if the starts do, and if entry_time equals exit_time, the interval is empty and the event doesn't count.
I assume entry_time > exit_time is impossible and not tested for.
Am I right?
(I believe my solution is correct under the above assumptions, yet it fails one test:

rows did not match expected
@@,when_happened ,visits_count
→ ,2019-04-01 05:05:05 +0000→2019-04-01 09:09:09 +0000,5

.)

The description leaves some things unspecified.

1. Is entry_time always smaller than exit_time? Can it be greater? Or equal? What then? Particularly for equal, does it momentarily increase the number of visitors by 1?
2. What if at some instant at least one visit ends and at least one starts, the two being disjoint sets? Do all these visits count as momentarily concurrent?
3. What if in case 2. there is additionally at least one visit at the same time with entry_time equal to exit_time?