4 ms·
> Just use UTC folks unless you have a really good idea why you shouldn't. If my whole team is based in Pacific Time, I'm gonna use something close to PT so I
by jedberg 1y ago
> Just use UTC folks unless you have a really good idea why you shouldn't.
If my whole team is based in Pacific Time, I'm gonna use something close to PT so I don't have to do hard math when reading raw logs.
If we're all US based, I still want something in the USA. The math is easier.
- kjehjrktlhl 1y agoTechnical debt. Please don’t.
- jrockway 1y agoYeah. I log in json + unix timestamp nanoseconds, and just convert it to something human-readable on display (github.com/jrockway/json-logs). I am not sure why logs need to be "pretty" at time of logging when they can be made pretty at time of display. Doing it at time of display means you can just use local time, and then nobody is confused.
- jedberg 1y ago[flagged]
- throwaway150 1y ago> Who hurt you? Nobody hurt them. Please don't do this kind of childish rebuttals. It looks really silly on HN. If you don't want to use UTC, that's one thing. You do you. But there are reasons for sane professionals (who weren't hurt by anybody) to expect their coworkers to use UTC when possible. Because using local timezone leads to some problems including the one in TFA.
- hobs 1y agoWell me, I have been burned by fixing this UTC bug at like 8 companies and overall more than four year of my life (between other things, each project took at least six months of people poking at things) because at an eventual scaling point it starts biting your ass everywhere in every service. Just because it worked once doesn't mean it's good.
- anonymars 1y agoI find all the holier-than-thou UTC worship especially ironic given that this post is about recurring scheduled tasks, for which naïve UTC almost never provides the expected results UTC is the right choice for representing specific moments in time (so yes, log timestamps) but there are so many pitfalls outside of that narrow use case
- onraglanroad 1y agoHard math. Ah right, I think it's not till the third year of a mathematics degree that you deal with "subtracting 8"! :)
- BenjiWiebe 1y agoI'm able to subtract 8, but if I'm scanning logs it's one more thing to process. If it's local time I know instantly when something happened, without having to do mental math. Is there anything wrong with ISO8601 (including timezone offset) for storing times? They're in my local time, but they can be accurately converted to any other timezone.
- onraglanroad 1y agoNo problem as long as it's all local, but it's a big annoyance to the other teams if I'm trying to coordinate with the West US team who're on PT, the East coast on ET, Europe on CET, India on IST, Australia on BBQ... It's just easier for everyone if we agree on UTC and everyone knows their own offset.
- jedberg 1y agoDon't forget changing the day 1/3 of the time. But more importantly, if I'm scrambling to solve an incident, the last thing I want to do is deal with time conversions in my head.
- onraglanroad 1y agoYou just do it once and think in UTC going forward. But as I said to the other person, if you're only dealing with one timezone it's fine, just when you have multiple it's a lot easier to just deal with one time and let everyone convert. I'd expect everyone who works in computer related jobs to know their UTC offset.
- adammarples 1y agoWhy not just store everything utc but add a local time to the logging along with it?
- jedberg 1y agoNowadays you could probably pull that off, most tools support quickly changing the time on the fly.
- joeiq 1y ago`date -u` gives you current UTC time when the arithmetic trips you up.