Skip to content

time: better handling of overflow in time.Time #71979

Open
@neild

Description

@neild

The time.Time type has a large, but finite range. The time package does not, so far as I can determine, document what this range is.

A Time can represent instants billions of years in the past or future. So far as I can tell, we've taken a general attitude that instants outside the probable lifespan of the human species are out of scope for the package and can be ignored.

For example, time.Unix converts a Unix timestamp (seconds & nanoseconds since the Unix epoch) to a Time. It documents the handling of out-of-range values only by saying:

Not all sec values have a corresponding time value. One such value is 1<<63-1 (the largest int64 value).

Functions such as time.AddDate do not document their behavior on overflow.

Most programs will never encounter out-of-range dates. (If Go proves to be unexpectedly durable on geologic time scales, we can leave the problem of increasing the size of the time.Time seconds counter to future generations.) However, a program handling adversarial inputs (such as a very large Unix timestamp) may be induced to overflow a time.Time, with surprising and undocumented results.

We could harden the time package a bit more against overflow. Some specific functions that we might harden:

  • time.Unix could either saturate or return the zero time when provided with an out-of-range value.
  • time.Add and time.AddDate could saturate rather than wrapping on overflow.
  • time.Round could either truncate or saturate on overflow.

There might be others I'm missing.

Alternatively, we could leave the implementation alone and document what validation users should perform to adequately defend against adversarial inputs to time.Unix.

Edit: Thanks to @kuprumxyz for bringing potential security issues in time overflow to our attention.

Metadata

Metadata

Assignees

No one assigned

    Labels

    LibraryProposalIssues describing a requested change to the Go standard library or x/ libraries, but not to a toolNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions