4 ms·
Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.
by burnt-resistor 1y ago
Always run production systems in the Etc/UTC timezone. This eliminates an entire class of problems while only creating minor inconveniences.
- Tepix 1y agoFor servers, i agree 100%. For desktop systems, not so much.
- actionfromafar 1y agoEastern Standard Tribe, represent!
- kstrauser 1y agoI appreciated the reference.
- kawsper 1y agoHow else could you tell what time it is on the servers?
- raverbashing 1y agoThat's easy, if you're Walmart just use the TZ of your corporate HQ (That's what I heard anyway)
- kstrauser 1y agoMy 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 1y agoBut on which side? :)
- kstrauser 1y agoThere can be only one!
- ThePowerOfFuet 1y agoGoogle's internal timestamps are in Pacific Time, too.
- madcaptenor 1y agoI work for a different company headquartered in the central time zone and we also do this. On some systems.
- bornfreddy 1y agoIt 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.
- macintux 1y agoI 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.
- ta1243 1y ago> 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 1y agoPostgres always stores date/time values in UTC (if they are timezone-aware)
- macintux 1y agoThese are strings. And not Postgres.
- stubish 1y agoEven 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).
- bayindirh 1y agoYou 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.
- bityard 1y agoI 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 1y agoAre you at Google? Because they also keep using US/Pacific timezone in every incidents where it affects everyone over the globe
- zappb 1y agoThat description could match nearly any tech company in the Bay Area or Seattle and everything along the coast.
- burnt-resistor 1y agoHow provincial. There are other ways.