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

Future-proofing date and time functionality #739

Open
DizzyHSlightlyVoided opened this issue Dec 9, 2024 · 2 comments
Open

Future-proofing date and time functionality #739

DizzyHSlightlyVoided opened this issue Dec 9, 2024 · 2 comments

Comments

@DizzyHSlightlyVoided
Copy link

The Year 2038 problem is right around the corner compared to 1995. There appears to be several problems in Fuzzball MUCK:

  • The basic fact that dates are stored in signed 32-bit integers, because all arithmetic involves 32-bit integers.
  • This means that you get overflows when adding and subtracting time to and from {secs} for dates later than 03:14:07 UTC on 19 January 2038
  • The fact that {convtime} and other date and time functions only support two-digit years; they should probably at least allow four-digit years, just for disambiguation purposes, but that's also a fairly straightforward way of future-proofing things. 2038 is closer to 2070 than 1970, after all.

This could be mitigated by either updating the existing mathematical functions to use 64-bit integers, or (for backwards-compatibility) adding new functions (i.e. {secs64}, {add64}, etc). I'm not sure what to do about the two-digit years.

@tanabi
Copy link
Collaborator

tanabi commented Dec 10, 2024

I think its fine to convert to 64 bit integers. We're at a point where even if you wanted to run a MUCK on old hardware (Ultrasparc, Alpha, etc.) you still have solid 64 bit support.

As for convtime, etc., the first step will be to make a list of all these methods, then we can look at them and figure out what to do. Perhaps we can parse them as either 2 digit or 4 digit based on the number of digits in the year position. If that is not feasible, we'll need to make new versions of these calls for those that care enough about the problem to do something about it :)

@DizzyHSlightlyVoided
Copy link
Author

As for convtime, etc., the first step will be to make a list of all these methods, then we can look at them and figure out what to do. Perhaps we can parse them as either 2 digit or 4 digit based on the number of digits in the year position. If that is not feasible, we'll need to make new versions of these calls for those that care enough about the problem to do something about it :)

The MPI ref has a section on time functions. Seems like the only relevant one is {convtime}; looking deeper, it seems that {ftime} allows you to convert seconds to date and time in an arbitrary format, but there doesn't appear to be any corresponding functions for the reverse.

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

2 participants