Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.

▲

macintux 4 days ago | parent | next [-]

I work with a development team who manages data integration and migration for massive datasets, and they have sensibly set a standard that every date/time value they store in their databases will be UTC.

But they explicitly or implicitly have also decided not to store the timezone in the strings, so every single value is technically ambiguous. Absolutely drives me crazy.

Update: since there have been questions, these are strings, not native datetime values.

▲

stubish 3 days ago | parent | next [-]

Even if you stored the timezone, the values are technically ambiguous. Even when you are using globally unique timezone identifiers like 'America/New_York' instead of 'EST' and its several meanings. A timestamp such as '2025-09-13 13:00 America/New_York' could end up referring to a different instant next week due to a correction in the timezone database. Unlikely for this sort of problem to happen and need correcting in major timezones, but it has happened for less popular and historical timezones. The way for them to be non-ambiguous, representing an unchangable instant in time, is to store the timestamp converted to a timezone that will never have retroactive changes and has no daylight savings time transitions, such as UTC. At which point, storing the timezone identifier is redundant (and violates the principle of not allowing illegal values to be represented if you follow that).

	▲	macintux 3 days ago \| parent [-]
		I feel strongly that a string time value with no specified timezone is dangerous. You have to make certain it is always handled as UTC, and if you export it to another system without making the timezone explicit, or anyone who is unfamiliar with the convention views it, you’ve lost the guarantee. When you’re shuffling around petabytes of data, adding another few megabytes to include the “Z” at the end of every timestamp is hardly a major expense.

▲

oftenwrong 2 days ago | parent | prev | next [-]

In many systems it is reasonable not to include a zone. Usually that goes hand-in-hand with the desire to use a more compact representation, such as storing a numerical timestamp with a customary interpretation (usually UTC or TAI). If you must store a string, you may as well include a zone. Using ambiguously-zoned timestamps is an invitation for bugs. I feel your pain.

▲

ta1243 4 days ago | parent | prev | next [-]

> they have sensibly set a standard that every date/time value they store in their databases will be UTC.

Not sensible at all for future date/times.

▲

shawnz 4 days ago | parent | prev [-]

Postgres always stores date/time values in UTC (if they are timezone-aware)

	▲	macintux 4 days ago \| parent [-]
		These are strings. And not Postgres.

▲

bityard 3 days ago | parent | prev | next [-]

I work for a company with servers, employees, and customers in basically every time zone around the world. And yet every server, internal tool, and workflow uses Pacific time. UTC is used precisely nowhere. Setting aside the issues of DST, I imagine it's convenient for the employees and managers in HQ but absolute madness for everyone else.

▲

a012 3 days ago | parent | next [-]

Are you at Google? Because they also keep using US/Pacific timezone in every incidents where it affects everyone over the globe

	▲	zappb 3 days ago \| parent [-]
		That description could match nearly any tech company in the Bay Area or Seattle and everything along the coast.

▲

burnt-resistor 3 days ago | parent | prev [-]

How provincial. There are other ways.

▲

Tepix 4 days ago | parent | prev | next [-]

For servers, i agree 100%. For desktop systems, not so much.

▲

kawsper 4 days ago | parent | next [-]

How else could you tell what time it is on the servers?

▲

raverbashing 4 days ago | parent [-]

That's easy, if you're Walmart just use the TZ of your corporate HQ

(That's what I heard anyway)

▲

kstrauser 4 days ago | parent | next [-]

My non-Walmart startup was expanding from California to other regions many years ago, and there was some debate about whether we’d use UTC or America/Los_Angeles globally. I was part of Team Over My Dead Body.

▲

actionfromafar 3 days ago | parent [-]

But on which side? :)

	▲	kstrauser 3 days ago \| parent [-]
		There can be only one!

▲

madcaptenor 3 days ago | parent | prev | next [-]

I work for a different company headquartered in the central time zone and we also do this. On some systems.

▲

ThePowerOfFuet 4 days ago | parent | prev [-]

Google's internal timestamps are in Pacific Time, too.

▲

actionfromafar 4 days ago | parent | prev [-]

Eastern Standard Tribe, represent!

	▲	kstrauser 4 days ago \| parent [-]
		I appreciated the reference.

▲

bornfreddy 4 days ago | parent | prev | next [-]

It also makes sense. Timezone is user specific - if you have users from all over the globe, they will need different settings, so this should be set in frontend.

▲

bayindirh 4 days ago | parent | prev [-]

You can also run in UTC+$YOUR_OFFSET timezone if you don't use DST.

On the other hand, UTCx timezones are not silver bullets if your fleet is a part of a multi-continent federation.