[for David] Rating availability for future eps uneven

@MAT13 wrote:
Hey David, take a look at season five of Magnum P.I. as an example...

https://www.tvmaze.com/shows/32819/magnum-pi/episodes

...you can see that episode 5x11 is set to air in October 2023 and because it is set in future noone can rate it, there is no rating option available.

However, episodes from 5x12 to 5x20 that come after can be rated even though they're even more in the future.

This is because they don't have release date set. And I think you made this like this because for many older episodes we don't always know release date and they are left without release date. So for episodes without release date set, you cannot distinguish between those that are future or past ones.

This may be low priority, but one way this could be handled is by comparing episode numbers. For example if 5x11 has date set in future, then all number for episodes after that can be safely assumed that they too will air in the future so you may check that. Or you may simply disregard this rating thing altogether and just let future episodes be rated without any verification. Or do you think cases like this aren't often and how it's currently handled is good enough?

I believe but don't quote me. The change to not be able to vote for episodes set in the future with an air date set, means that when an air date is added to the other episodes any previous votes are cleared. The reason you can vote for an episode without any airdate added is that we will sometimes have full seasons of a show with the airdate not known but they haven't definately aired in their entirety, so people should have the option to vote on them. I'll tag @david in case any of what I've said isn't correct. 

@TomSouthwell wrote:
(...) means that when an air date is added to the other episodes any previous votes are cleared.

This part isn't correct.

Long story short: we're not currently doing this because it'd make the code a lot more complicated/slower, for something that isn't extremely important. But I'll keep the suggestion in mind, thanks!

@david wrote:
Long story short: we're not currently doing this because it'd make the code a lot more complicated/slower, for something that isn't extremely important. But I'll keep the suggestion in mind, thanks!

Okie-dokie :D