0

I see that by default, timestamps() is used. This strikes me as fragile, as there are a number of ways for timestamps to go wrong due to a number of moving parts, all of which could have different timezones.

Is there a reason to ever prefer timestamps() over timestampsTz()? The ones I've come up with so far are:

  • If the column is used in some kind of ID or ID-like manner, such as sharding, timestamps() would be preferred.
  • It seems timestampsTz() might be a Postgres thing, so not MySQL? But timestampsTz() doesn't have any gotchas listed in the docs. If timestampsTz() doesn't do anything in MySQL, what would be the best alternative for timezone-aware timestamp columns?

Thanks for the help!

  • If zone information is not critical, no issues with timestamps. Loads of related questions here: Pls. have a look at these to get a good insight: https://softwareengineering.stackexchange.com/questions/196156/what-is-the-best-practice-for-saving-timezones-in-the-database https://stackoverflow.com/questions/2532729/daylight-saving-time-and-time-zone-best-practices https://stackoverflow.com/questions/3446906/how-to-store-timezoneinfo-objects-in-a-database – user3532758 Jul 29 '20 at 01:01
  • Oof, this makes it sounds like I would be better off just storing the integer unix timestamp, since the only operation I care about is whether or not a given timestamp falls within X seconds of the present. Comments on using an int/bigint for my purposes? –  Jul 29 '20 at 01:14

0 Answers0