Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HammerTime stops applying DST for dates after 2038 #93

Open
nightpool opened this issue Jul 23, 2022 · 3 comments
Open

HammerTime stops applying DST for dates after 2038 #93

nightpool opened this issue Jul 23, 2022 · 3 comments

Comments

@nightpool
Copy link

nightpool commented Jul 23, 2022

Steps to reproduce:

  1. 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.
  2. Type in "2038" (or any subsequent year) for the year value.
  3. Notice that the timestamp is calculated incorrectly, and the displayed time is one hour off from the time that is typed in

screenshot of timestamp calculated incorrectly for 2038-06-01

For comparison, here's are two timestamps that are correctly calculated:

Year prior to 2038: Non-DST date:
screenshot of timestamp calculated correctly for 2037-06-01 screenshot of timestamp calculated correctly for 2038-03-01

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

@DJDavid98
Copy link
Owner

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.

@OssomUmbra
Copy link

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.

@Jessuhh
Copy link

Jessuhh commented Apr 12, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants