[giovannibonetti]

> Queries for business metrics are usually scattered, written by many people, and generally much less controlled. So do what you can to make it easy for your business to get the metrics it needs to make better decisions.

A simple but useful thing is setting the database default time zone match the one where most of your team is (instead of UTC). This reduces the chance your metrics are wrong because you forgot to set the time zone when extracting the date of a timestamp.

[xyzzy_plugh]

I cannot overstate how bad this advice is. Everything should be UTC by default. You can explicitly use timestamp with timezones and frankly it's trivial to query something like midnight-to-midnight PST. Your team should learn this as early as possible.

Build tooling around this, warn users, hell, educate them, but don't set up foot-guns like non-UTC.

If I see a timestamp without a timezone, it must always be UTC. To do anything else is to introduce insanity.

[higeorge13]

This. I once joined a company with local timezone per deployment and it was a nightmare. Not only in terms of development and debugging, but even for all the support tools required and the numerous bugs we found.

I insisted that all the tools that were going to be installed under my watch would be UTC, and never experienced any time issue on them.

[sethammons]

We went this route and ended up with a db set to pst and some servers based on Chicago time. Endless time bugs. Pick one timezone for everything or just use unix timestamps.

[dehrmann]

I disagree on this because handling DST is error-prone.