Check year range in both side

[gnattu]

We cannot expect all users will always tag the files in the year tag with valid years. A lot of them will abuse this tag field to tag a full date in pure number, like 19991231. Such date is not parseable by DateTime.TryParse and is not within valid year range for DateTime constructor. We check if that is the case before creating a new DateTime instance.

See jellyfin/jellyfin#13669 and jellyfin/jellyfin#11576

For some format (like mp4) this case is already handled and fallback to the smallest date: jellyfin/jellyfin#13514

This PR makes the explicit years to also behave similar to that, which is an acceptable behavior when the user has specified an invalid year.

[Zeugma440]

We cannot expect all users will always tag the files in the year tag with valid years. A lot of them will abuse this tag field to tag a full date in pure number, like 19991231.

Thanks for the insight; I didn't realize that thing even existed.

For some format (like mp4) this case is already handled and fallback to the smallest date:

Falling back to 0 will certainly prevent the crash, but I'm sure we can do better than that in terms of added value.

Lemme work on my test cases, I'll get back to you with suggestions. The tricky part is to determine what's acceptable regarding specs and what we can force.

[Zeugma440]

Just pushed an update to handle that case more gracefully : any Year field recognized as a Date will be used to value the Date field instead. I'm closing this PR (thanks anyway for bringing that up~)

[Zeugma440]

Fix is available on today's v6.19