When you search for things on the internet, sometimes you find treasures like this post on logging, e.g. creating meaningful logs. This post is authored by Brice Figureau (found on Twitter as @_masterzen_). His blog clearly shows he understands the multiple aspects of DevOps and is worth a visit. Our thanks to Brice for letting us […]
You lose information when DST kicks in - which is not great. It is trivial to convert to any timezone so there is little point in logging in anything but UTC and keeps everything consistent. Especially when comparing dates from servers in different timezones.
My job would be much easier if everything was stored internally in UTC. But that boat sailed long before I started working there. Instead, I get to convert from local server time to UTC to local client time. 😭
Logging in local time is fine as long as the offset is marked. Everything else I agree with you though
You lose information when DST kicks in - which is not great. It is trivial to convert to any timezone so there is little point in logging in anything but UTC and keeps everything consistent. Especially when comparing dates from servers in different timezones.
My job would be much easier if everything was stored internally in UTC. But that boat sailed long before I started working there. Instead, I get to convert from local server time to UTC to local client time. 😭
You don’t lose info as long as the offset is marked correctly
I get your point, but that’s just UTC with extra steps. I feel that there’s no valid justification for using two entries instead of just one.