Consider a replacement for `moment-timezone-with-data-1970-2030.js`

[Schnark]

This isn't urgent yet, but the year 2030 is approaching, so rather sooner than later something should be done about the file moment-timezone-with-data-1970-2030.js. After the year 2030 it will no longer be useful for current dates, so that is a definite deadline. But as the data is also used for future dates, this will be an issue even earlier. If you want to handle dates up to 5 years into the future (like the file moment-timezone-with-data-10-year-range.js allows), then something should be done within the next year.

Possible alternatives are:

• Simply build a moment-timezone-with-data-1970-2040.js file, and discuss the matter again in 10 years (if this library lives that long).
• Create the data for a range with a fixed start in 1970, but a moving end at currentYear + 5 (like moment-timezone-with-data-10-year-range.js ), or even currentYear + 10 (if users of moment-timezone-with-data-1970-2030.js expect it to go further into the future).

[gilmoreorless]

You're right, this is going to be a problem. We've seen a lot of issues when deprecating/removing the old hard-coded 10-year files (2010-2020 & 2012-2022). Renaming or removing these files is technically a breaking change, but leaving them in place beyond their range of dates also causes confusion. (People maintaining old projects were often unaware they were actually using these hard-coded files, and wondered why calculations broke when we hit 2023.) I added a deprecation warning for the 2012-2022 files in #1036, and we're going to need a similar plan for the 1970-2030 files.

I like your idea of basing the end date on a rolling currentYear + <n>. I'm going to leave this issue open as a reminder that this needs a solution implemented.