> 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.
Technical debt. Please don’t.
Yeah. 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.
[flagged]
> 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.
I 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
Well 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.
Hard math. Ah right, I think it's not till the third year of a mathematics degree that you deal with "subtracting 8"! :)
Don'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.
You 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.
I'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.
No 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.
Why not just store everything utc but add a local time to the logging along with it?
Nowadays you could probably pull that off, most tools support quickly changing the time on the fly.
`date -u` gives you current UTC time when the arithmetic trips you up.