# Unix Timestamp (seconds) Key: `datetime.epoch.unix_seconds` Seconds since 1970-01-01 00:00:00 UTC. The standard epoch representation used in most programming languages and systems. Page: Samples: `1705312200`, `1577836799`, `1000000000` ## Background ### Origin The earliest versions of Unix time had a 32-bit integer incrementing at a rate of 60 Hz.[[1]](https://en.wikipedia.org/wiki/Unix_time) Midnight on 1 January 1971 and 1 January 1972 were both used as epochs during the early development of Unix.[[1]](https://en.wikipedia.org/wiki/Unix_time) The precision of Unix time was changed to count in seconds in order to avoid short-term overflow.[[1]](https://en.wikipedia.org/wiki/Unix_time) The current epoch of 1 January 1970 00:00:00 UTC was selected arbitrarily by Unix engineers because it was considered a convenient date to work with.[[1]](https://en.wikipedia.org/wiki/Unix_time) POSIX defines seconds since the Epoch as a value that approximates the number of seconds that have elapsed since the Epoch.[[2]](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html) The POSIX definition relates a Coordinated Universal Time name to seconds since the Epoch through a C-language expression built from the seconds, minutes, hours, day of the year and year.[[2]](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html) POSIX states that, as represented in seconds since the Epoch, each and every day shall be accounted for by exactly 86400 seconds.[[2]](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html) POSIX leaves the relationship undefined if the year is before 1970 or the value is negative.[[2]](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html) The 2001 edition of POSIX.1 rectified a faulty leap year rule in the definition of Unix time.[[1]](https://en.wikipedia.org/wiki/Unix_time) In Unix time, every day contains exactly 86400 seconds.[[1]](https://en.wikipedia.org/wiki/Unix_time) Unix time differs from both Coordinated Universal Time and International Atomic Time.[[1]](https://en.wikipedia.org/wiki/Unix_time) Python's documentation says leap seconds are excluded from seconds since the epoch on all POSIX-compliant platforms.[[3]](https://docs.python.org/3/library/time.html) ### Use Unix time is used as a mechanism for storing timestamps in a number of file systems, file formats and databases.[[1]](https://en.wikipedia.org/wiki/Unix_time) Python's time.time() returns the time in seconds since the epoch as a floating-point number.[[3]](https://docs.python.org/3/library/time.html) PostgreSQL's to\_timestamp(double precision) converts a Unix epoch value, in seconds since 1970-01-01 00:00:00+00, to a timestamp with time zone.[[4]](https://www.postgresql.org/docs/current/functions-datetime.html) DuckDB's to\_timestamp function converts seconds since the epoch to a timestamp with time zone.[[5]](https://duckdb.org/docs/current/sql/functions/timestamptz.html) RFC 7519 defines the JSON Web Token NumericDate as a JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC, ignoring leap seconds.[[6]](https://www.rfc-editor.org/rfc/rfc7519) JavaScript Date objects count milliseconds, not seconds, since the midnight at the beginning of January 1, 1970, UTC.[[7]](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) Treat a seconds value as an instant in UTC, and apply a local time zone only when you display it. (Meridian's view) Unix time passed 1000000000 seconds on 2001-09-09T01:46:40Z.[[1]](https://en.wikipedia.org/wiki/Unix_time) A signed 32-bit value of Unix time cannot represent dates after 19 January 2038 at 03:14:07 UTC, which is known as the year 2038 problem.[[1]](https://en.wikipedia.org/wiki/Unix_time) If a source system stores these values in a 32-bit integer column, check what it does with dates beyond 2038 before you trust them. (Meridian's view) ### Where you'll meet it Stripe's API reference describes the created attribute of a Charge as measured in seconds since the Unix epoch.[[8]](https://docs.stripe.com/api/charges/object) GitHub's REST API documentation gives the x-ratelimit-reset header in UTC epoch seconds.[[9]](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api) The OpenSky Network's REST API reports time\_position and last\_contact in state vectors as Unix timestamps in seconds.[[10]](https://openskynetwork.github.io/opensky-api/rest.html) ## Sources 1. [Unix time](https://en.wikipedia.org/wiki/Unix_time) — secondary source 2. [General Concepts](https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html) — standard 3. [time — Time access and conversions](https://docs.python.org/3/library/time.html) — documentation 4. [9.9. Date/Time Functions and Operators](https://www.postgresql.org/docs/current/functions-datetime.html) — documentation 5. [Timestamp with Time Zone Functions](https://duckdb.org/docs/current/sql/functions/timestamptz.html) — documentation 6. [RFC 7519: JSON Web Token (JWT)](https://www.rfc-editor.org/rfc/rfc7519) — standard 7. [Date - JavaScript \| MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date) — documentation 8. [The Charge object](https://docs.stripe.com/api/charges/object) — organisation 9. [Rate limits for the REST API](https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api) — organisation 10. [OpenSky REST API](https://openskynetwork.github.io/opensky-api/rest.html) — organisation