Date decrease by 1day while formatting dates greater than 2037 for the timezones which have DayLightSaving

[SanthoshYAR]

0.5.32### Moment-timezone version which you use:

Version:

Note: many issues are resolved if you just upgrade to the latest version

Issue description:

When a date is formatted using moment js and if the year is greater than 2037 and the corresponding timezone has DST, date is formatted 1 day less

[ichernev]

Can you please provide exact examples, expected, actual results. Normally moment-timezone releases have DST info up until 2037 (well some have until 23xx but this is a bug : #768).

[mangeshwalhe]

Hello,
We are facing this issue. Requirement needs user to add a future date (date of retirement, lease end date), which in many usecases is beyond 1st January 2038. It is registered in GMT format, hence when users from APAC region add a date, it is rendered as previous date.
May I know the timeline planned for fixing this issue?

[wiznotwiz]

Bump - any updates here?

My use case is that I'm comparing dates to see if they're quarter-end dates. Unfortunately, after 2037, only Dec 31 is matching (while Mar 31, Jun 30, and Sept 30) are not matching. I'm not using time to check - only month # and day #. But, for example, 09/30/2039 is being seen as 09/28/2039 when using the moment(_date_).date() utility function. Note that .date() is working perfectly for finding my quarter-end dates until I pass in dates after Dec 2037 (i.e. 03/31/2038 doesn't get recognized as a quarter-end date).

[gilmoreorless]

The last few Moment Timezone releases (since 0.5.37) have increased the data range well past 2038. Can you try with the latest version and see if you're still having these issues?

[wiznotwiz]

That's good to know - we will look into upgrading Moment when we update packages this year! We're on 0.5.31. I'll report back here if we still have any trouble past 2038 after upgrading.

For anyone still on an older version, I ended up using JS's .getDate() and .getMonth() functions to accomplish my goal past the year 2038.

[gilmoreorless]

I'm going to close this as it looks like the data issue has been resolved.

As a side note, we're looking at a future compromise between data accuracy and file size. At some point we'll likely lock the maximum date range in the data to <year of release> + 100 (e.g. 2123 for any release built this year).
See #1039 for details. Since you've been directly affected by data range issues, let me know if that would cause a problem.