Skip to content

Future-proofing date and time functionality #739

@DizzyHSlightlyVoided

Description

@DizzyHSlightlyVoided

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions