Increase auto_max_age from 30 to 300 - #15436

Thank you for your contribution to Astropy! 🌌 This checklist is meant to remind the package maintainers who will review this pull request of some common things to look for.

• Do the proposed changes actually accomplish desired goals?
• Do the proposed changes follow the Astropy coding guidelines?
• Are tests added/updated as required? If so, do they follow the Astropy testing guidelines?
• Are docs added/updated as required? If so, do they follow the Astropy documentation guidelines?
• Is rebase and/or squash necessary? If so, please provide the author with appropriate instructions. Also see instructions for rebase and squash.
• Did the CI pass? If no, are the failures related? If you need to run daily and weekly cron jobs as part of the PR, please apply the "Extra CI" label. Codestyle issues can be fixed by the bot.
• Is a change log needed? If yes, did the change log check pass? If no, add the "no-changelog-entry-needed" label. If this is a manual backport, use the "skip-changelog-checks" label unless special changelog handling is necessary.
• Is this a big PR that makes a "What's new?" entry worthwhile and if so, is (1) a "what's new" entry included in this PR and (2) the "whatsnew-needed" label applied?
• Is a milestone set? Milestone must be set but we cannot check for it on Actions; do not let the green checkmark fool you.
• At the time of adding the milestone, if the milestone set requires a backport to release branch(es), apply the appropriate "backport-X.Y.x" label(s) before merge.

I worry about 300 days being too long - see comment in #14756.

You are right that the line for the leap-second file has to be changed. With a value larger than 180, the code will assume that even leap second files that are expired are "good enough" -- and then give a warning because the file is expired at the end. Offsets smaller than 0 should definitely not be allowed.

From the new discussions in #14756 , sounds like I should just close this without merge while you all debate somemore?

Given the failures, I think the very simple solution does not work, so maybe indeed best to just abandon for now... I think the people bothered by the short update time should find a solution that does not break the workflow of those who rely on it...

I think the people bothered by the short update time should find a solution

The people who are bothered are the service providers, unfortunately. Users can opt to turn download off (we have a whole section of doc dedicated to that) but providers cannot control who requests their files.

I also proposed this but was rejected:

• Change default auto_download to False for IERS tables #15248

Anyway, let's move the discussion back to the original issue. Thanks!