You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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 :)
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.
The Year 2038 problem is right around the corner compared to 1995. There appears to be several problems in Fuzzball MUCK:
{secs}
for dates later than 03:14:07 UTC on 19 January 2038{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.The text was updated successfully, but these errors were encountered: