Hacker News .hnnew | past | comments | ask | show | jobs | submitlogin
PostgreSQL Timestamps and Timezones: What You Need to Know–and What You Don’t (yugabyte.com)
27 points by lobo_tuerto on Feb 13, 2022 | hide | past | favorite | 5 comments


I know its off topic, but I created a tool which converts simple text to PostgreSQL tables with foreign key relation ships, It reduces time to create database structure

https://text2db.com/


>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


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: