HammerTime stops applying DST for dates after 2038
Opened this issue · 3 comments
Steps to reproduce:
- Navigate to https://hammertime.cyou/.
a. If you're not in a locale that's currently experiencing DST, you'll need to first select a locale that experiences DST and type in a date that is subject to DST (for example: America/New_York and July 1st). Most people won't need this step, but it's included for completeness. - Type in "2038" (or any subsequent year) for the year value.
- Notice that the timestamp is calculated incorrectly, and the displayed time is one hour off from the time that is typed in
For comparison, here's are two timestamps that are correctly calculated:
| Year prior to 2038: | Non-DST date: |
|---|---|
 |
 |
Note that the problem here is in the calculation of the timestamp itself: the displayed times are correct, as far as I can tell, and match with how discord displays the calculated unix timestamps (e.g. <t:2158988400:f>), as well as how wolfram alpha displays them: https://www.wolframalpha.com/input?i=2158988400+seconds+after+unix+epoch
Sorry for the radio silence on this but I am at the mercy of date processing libraries here, I didn't write most of the low-level code that deals with dates on the site and this is not something I am easily able to diagnose and fix.
I suspect this is due to outdated/missing/wrong data in Moment.js as the library is no longer maintained. I expect to switch to dayjs fully at some point which should eliminate most date processing issues like this, but until I actually do that I can't verify that it will solve this. I left the issue open because of this, maybe this will be fixed by said replacement eventually, until then there's not much I can do personally.
Looking in to it, appearntly it's an issue with 32bit intergers, which Unix time is based on.
Using a 64bit interger for Unix time appearntly would fix the issue, don't know how hard that will be, but there's the solution i found.
This seems like an issue that has to do with year 2038 problem: https://en.m.wikipedia.org/wiki/Year_2038_problem
Just thinking about it, it seems most likely that it is indeed a moment.js issue, like David said