The way I see it, it isn't true that "Select Count() is BAD!" I suspect this arose because people were using MySQL with a storage engine for which SELECT COUNT(*) queries for the entire table would retrieve a cached row count, then they switched to another storage engine and lo, it was slow because there was no such cached row count, so they jumped to this conclusion. Since the issue is with the full table scan, replacing that COUNT(*) with a query of the entire table that you then take the row count of the result set isn't necessarily going to be any faster, and it might even be slower. I think that the fast solutions tend to involve stuff like caching the row count yourself, and periodically synchronising it by doing an out-of-band full table scan with COUNT(*).
But, this is not what you're doing here. You're not doing a COUNT(*) to get the row count of the entire table; rather, you have a particular result set and want to count the number of rows. I'm inclined to say that COUNT(*) would be the right solution here as it expresses that you wish to count the number of rows of the result set; COUNT(id) for id being a non-NULL primary key should work too and corresponds to more closely to the current query, but it also introduces the requirement of id being not null and indexed, otherwise you might not be counting the rows you want to count, or the lack of an index could introduce a time penalty.
Speaking of index though, my feeling is that that could ultimately be why the query is slow: it looks like listing is a foreign key, so presumably it is already indexed, but if time isn't indexed, perhaps a full table scan needs to be done to determine the rows to select that meet your time constraints, and this could be slow for a sufficiently large table.