3 ms·
It depends on your use-case. You should also be aware of the Year 2038 problem [0]. What are you trying to achieve? [0] https://en.wikipedia.org/wiki/Year_203
by TheAceOfHearts 8y ago
It depends on your use-case. You should also be aware of the Year 2038 problem [0].
What are you trying to achieve?
[0] https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- robbiep 8y agoLargely timestamping. Accuracy to a high level (leap seconds) is irrelevant. Aware of 2038 problem, assume we will have some fun along the way to there along with the rest of the unix world!
- TheAceOfHearts 8y agoStoring Unix timestamps in a 64-bit signed integer field would probably be fine in that situation. The only downsides that come to mind are that you'd have to manually convert the number to an actual date when using it, and that you'd lose easy access to date-related functionality in the database.
- jeltz 8y agoBut also totally pointless since PostgreSQL's timestamptz type also uses 64 bits.