PostgreSQL Timestamps and Timezones: What You Need to Know–and What You Don’t(blog.yugabyte.com)
blog.yugabyte.com
PostgreSQL Timestamps and Timezones: What You Need to Know–and What You Don’t
https://blog.yugabyte.com/postgresql-timestamps-timezones/
5 comments
>The only way to future-proof your code so that it will continue to give currently correct results no matter what rule changes are made is always to persist data as timestamptz values and to let the system—kept current with the tz database—work its magic according to the rules that it presently embodies.
Key take away IMO
Key take away IMO
Yep. That's what I do. Preserves your sanity and allows you to order events across timezones and time changes.
hard to tell what is yugabyte and what is postgresql implementations.
YugabyteDB is a distributed, horizontally scalable SQL database providing CQL and PSQL APIs.
For PSQL API, it uses PostgreSQL 11.2. It does almost everything what Postgres does and takes that one step further by adding horizontal scalability built on top of raft consensus.
What’s unique with it: it’s basically Postgres. There is no different db paradigm squeezing in on top of Postgres. You can use foreign data wrappers (postgres_fdw), extensions (postgis 3.1, uuid-ossp, …) and you can write your own extensions which are the same as regular Postgres extensions (background workers, process utility hooks, query planner hooks), triggers, functions, everything…
It has a pretty unique take on Postgres tablespaces. A tablespace in YugabyteDB allows pinning either a whole table or a primary key range to a specific set of storage nodes. That allows for placing arbitrary data within, for example, a dedicated geographical location. This is awesome for data compliance.
For PSQL API, it uses PostgreSQL 11.2. It does almost everything what Postgres does and takes that one step further by adding horizontal scalability built on top of raft consensus.
What’s unique with it: it’s basically Postgres. There is no different db paradigm squeezing in on top of Postgres. You can use foreign data wrappers (postgres_fdw), extensions (postgis 3.1, uuid-ossp, …) and you can write your own extensions which are the same as regular Postgres extensions (background workers, process utility hooks, query planner hooks), triggers, functions, everything…
It has a pretty unique take on Postgres tablespaces. A tablespace in YugabyteDB allows pinning either a whole table or a primary key range to a specific set of storage nodes. That allows for placing arbitrary data within, for example, a dedicated geographical location. This is awesome for data compliance.
https://text2db.com/