--- title: All Your GUCs in a Row: integer_datetimes | daily.dev description: PostgreSQL has announced the `integer_datetimes` parameter to every connecting client since version 8.0, even though it has had only one possible value since... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: integer_datetimes | daily.dev og:description: PostgreSQL has announced the `integer_datetimes` parameter to every connecting client since version 8.0, even though it has had only one possible value since... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu og:image: https://api.daily.dev/og/posts/NobISozqU.png og:image:alt: All Your GUCs in a Row: integer_datetimes og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Your GUCs in a Row: integer_datetimes **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 4 min read · 1 upvotes · 1 comments ## Summary PostgreSQL has announced the `integer_datetimes` parameter to every connecting client since version 8.0, even though it has had only one possible value since PostgreSQL 10. The post explains the historical context: datetime values were originally stored as double-precision floats (counting seconds from 2000-01-01), which caused precision loss and subtle bugs. The integer format (64-bit microseconds from the same epoch) was introduced as a compile-time option in the 7.x era, became the default in 8.4, and became the only option in PostgreSQL 10 when Tom Lane removed the float build option after finding it was unused and buggy. The parameter persists in the connection startup protocol because binary-mode drivers must know the wire format to decode timestamps correctly — guessing wrong yields silently corrupt timestamps with no error. A historical example from 2010 shows an application writing float-format binary timestamps to an 8.4 server, producing dates around year 15000. The only remaining practical concern is `pg_upgrade`, which refuses to migrate a float-built cluster; dump and restore is the only option for any surviving pre-8.4 or pre-10 float-built clusters. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What does the integer_datetimes parameter in PostgreSQL actually do? It reports the internal storage format PostgreSQL uses for date/time types: an int64 counting microseconds since midnight, 2000-01-01, for timestamp and timestamptz values (and seconds fields in other time types), covering a range up to the year 294276. It replaced an original float8-seconds format that suffered precision loss and inexact arithmetic. Since PostgreSQL 10 it is a read-only preset always set to on. _Anyone debugging timestamp precision or binary protocol quirks in postgresql can dig deeper on daily.dev._ ### Why does pg_upgrade sometimes refuse to run between two PostgreSQL clusters? pg_upgrade compares the Date/time type storage line reported by pg_controldata between the old and new clusters and refuses to proceed on a mismatch. Since every PostgreSQL build since version 10 uses integer datetimes exclusively, this only matters for a surviving float-built cluster, hand-compiled before 8.4 or built with the removed --disable-integer-datetimes flag; such a cluster can only be migrated via dump and restore. _Teams planning a postgresql version upgrade can track these legacy gotchas on daily.dev._ ### Why does a PostgreSQL server announce integer_datetimes to every client at connection start even though it can only ever be on? The server reports it in the ParameterStatus messages sent before the client says anything so that binary-capable drivers know how to decode timestamp values on the wire. In binary mode, the eight bytes sent are the raw storage format, either an int64 of microseconds or, historically, a float8 of seconds, and a client that assumes the wrong format gets no error, just a silently wrong timestamp. _Developers working with postgresql's binary wire protocol can follow deep dives like this on daily.dev._ ## Community discussion Top comments from developers on daily.dev. **@trevorsuna** · 0 upvotes > This is a neat example of a protocol fossil that still protects real clients. Once binary timestamps cross the wire, keeping the capability signal is much safer than guessing; a wrong guess producing plausible but corrupt dates is exactly the kind of failure good compatibility tests should catch. ## Similar posts on daily.dev - [PostgreSQL to SQL Field Notes: Date & Time](https://daily.dev/posts/postgresql-to-sql-field-notes-date-time-nx1bbpygh) · DevBlogs · 0 upvotes · 1 comments - [All Your GUCs in a Row: extra\_float\_digits](https://daily.dev/posts/all-your-gucs-in-a-row-extra-float-digits-xfmhd6yck) · Planet PostgreSQL · 6 upvotes · 1 comments - [British Columbia, Time Zones, and Postgres](https://daily.dev/posts/british-columbia-time-zones-and-postgres-uiebxsyyj) · Crunchy Data · 0 upvotes · 0 comments - [10 best practices for timestamps and time zones in databases](https://daily.dev/posts/10-best-practices-for-timestamps-and-time-zones-in-databases-xhfzsegaw) · Tinybird · 2 upvotes · 1 comments --- Tags: [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"All Your GUCs in a Row: integer_datetimes","url":"https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu"},"datePublished":"2026-08-10T01:01:33.919Z","dateModified":"2026-09-14T06:05:26.634Z","description":"PostgreSQL has announced the `integer_datetimes` parameter to every connecting client since version 8.0, even though it has had only one possible value since...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/13c105ff6ec117b3960becbaf5c1bf94?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/13c105ff6ec117b3960becbaf5c1bf94?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":1,"discussionUrl":"https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":1}],"keywords":"postgresql","timeRequired":"PT4M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"All Your GUCs in a Row: integer_datetimes"}]} {"@context":"https://schema.org","@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu","comment":[{"@type":"Comment","text":"This is a neat example of a protocol fossil that still protects real clients. Once binary timestamps cross the wire, keeping the capability signal is much safer than guessing; a wrong guess producing plausible but corrupt dates is exactly the kind of failure good compatibility tests should catch.","datePublished":"2026-08-10T02:38:32.364Z","url":"https://daily.dev/posts/NobISozqU#c-deEBwPX70","author":{"@type":"Person","name":"Trevor Suna","url":"https://daily.dev/trevorsuna","image":"https://media.daily.dev/image/upload/s--dZ7gXxpp--/f_auto/v1784081551/avatars/avatar_EMoP47rpuw8DNjhp6R1b6?_a=BAMAMicg0"}}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-integer-datetimes-nobisozqu#faq","mainEntity":[{"@type":"Question","name":"What does the integer_datetimes parameter in PostgreSQL actually do?","acceptedAnswer":{"@type":"Answer","text":"It reports the internal storage format PostgreSQL uses for date/time types: an int64 counting microseconds since midnight, 2000-01-01, for timestamp and timestamptz values (and seconds fields in other time types), covering a range up to the year 294276. It replaced an original float8-seconds format that suffered precision loss and inexact arithmetic. Since PostgreSQL 10 it is a read-only preset always set to on. Anyone debugging timestamp precision or binary protocol quirks in postgresql can dig deeper on daily.dev."}},{"@type":"Question","name":"Why does pg_upgrade sometimes refuse to run between two PostgreSQL clusters?","acceptedAnswer":{"@type":"Answer","text":"pg_upgrade compares the Date/time type storage line reported by pg_controldata between the old and new clusters and refuses to proceed on a mismatch. Since every PostgreSQL build since version 10 uses integer datetimes exclusively, this only matters for a surviving float-built cluster, hand-compiled before 8.4 or built with the removed --disable-integer-datetimes flag; such a cluster can only be migrated via dump and restore. Teams planning a postgresql version upgrade can track these legacy gotchas on daily.dev."}},{"@type":"Question","name":"Why does a PostgreSQL server announce integer_datetimes to every client at connection start even though it can only ever be on?","acceptedAnswer":{"@type":"Answer","text":"The server reports it in the ParameterStatus messages sent before the client says anything so that binary-capable drivers know how to decode timestamp values on the wire. In binary mode, the eight bytes sent are the raw storage format, either an int64 of microseconds or, historically, a float8 of seconds, and a client that assumes the wrong format gets no error, just a silently wrong timestamp. Developers working with postgresql's binary wire protocol can follow deep dives like this on daily.dev."}}]} ```