What does a negative Unix timestamp mean, and where does code break on one?

The example is the Apollo 11 landing. NASA's National Space Science Data Center says "The LM landed at 20:17:40 UT", and NASA's mission timeline puts the same event within a second of that, so the exact second depends on rounding. This page uses that rounded second. To build the timestamp in JavaScript, use Date.UTC, which returns milliseconds since the epoch, so divide by 1000. Its month argument starts at 0, so 6 is July.

const seconds = Date.UTC(1969, 6, 20, 20, 17, 40) / 1000
console.log(seconds) // -14182940

JavaScript dates sit on both sides of the epoch. MDN says a Date can represent "±8,640,000,000,000,000 milliseconds, or ±100,000,000 (one hundred million) days, relative to the epoch." Plenty of other systems are less forgiving.

Fixed width types are the first trap. An unsigned type can't hold a negative number at all. A signed 32-bit count starts at -2,147,483,648, which is December 13, 1901 at 20:45:52 UTC, and nothing earlier fits. A 64-bit count reaches about 292 billion years in either direction. The other end of the 32-bit range has its own page: Year 2038 problem.

Python is the next place it breaks. The Python docs say fromtimestamp() may raise OverflowError when the value is outside what the platform's C functions support, and that it's common for this to be restricted to years 1970 through 2038. Starting from the epoch and adding a timedelta avoids that. The code below builds a datetime with a UTC time zone and prints the same moment as the example:

from datetime import datetime, timedelta, timezone
moment = datetime(1970, 1, 1, tzinfo=timezone.utc) + timedelta(seconds=-14182940)
print(moment.strftime('%Y-%m-%dT%H:%M:%SZ')) # 1969-07-20T20:17:40Z

MySQL fails quietly. `UNIX_TIMESTAMP()` only accepts dates starting at 00:00:01 UTC on January 1, 1970, and it returns 0 for any out of range date. That 0 reads as January 1, 1970, so a bad value can pass for a real one. PostgreSQL handles it: `EXTRACT(EPOCH ...)` returns negative numbers for timestamps before the epoch.

The last trap is division. The Go spec says integer division is "truncated towards zero", so dividing negative milliseconds by 1000 rounds toward zero instead of down. This Go code prints both results, in seconds:

package main
import (
    "fmt"
    "math"
)
func main() {
    ms := int64(-1500)
    fmt.Println(ms / 1000)                             // -1, which is 1969-12-31T23:59:59.000Z
    fmt.Println(int64(math.Floor(float64(ms) / 1000))) // -2, which is 1969-12-31T23:59:58.000Z
}

The first line prints -1, one second after the second that holds the value. The second line prints -2, the second that starts at 1969-12-31T23:59:58.000Z and contains -1500 milliseconds. Python's // and JavaScript's Math.floor round down like the second line.

Fractions follow the same rule. A timestamp of -1.5 is half a second after December 31, 1969 at 23:59:58 UTC, so truncating toward zero gives 23:59:59 instead. For the spreadsheet version of this conversion, see Unix timestamp in Excel and Google Sheets.