4 ms·
This is a common view I've seen. It usually starts like this " but we're all in <tz> so we should just use that so no one needs to do any maths." Then later w
by mattlondon 6y ago
This is a common view I've seen.
It usually starts like this " but we're all in <tz> so we should just use that so no one needs to do any maths."
Then later when operations spread to elsewhere it becomes "but most stuff is still done in <original tz> so we will still use that and everyone in other places will just need to deal with it and use our 'real' tz."
Then when you are operating in 3 or 4 or 5 or more locations it is too late to change anything and you are screwed because now you are in some provincial timezone for 50% of your systems - complete with clock changes - and the rest are a mess of either in UTC or some other TZ local to that server with their own different clock changes to the original TZ. Chaos.
And you can guarantee that none of the log files have TZ in their timestamps because of that original "we're only in one TZ" mindset so why bother saying what TZ it is... From then on every time you look at a log or a database or a web UI or whatever you need to double guess the timezone.
For those that come after you, please please please if you can't use UTC then at the very least always show the timezone in your log files/UIs/etc even of it seems redundant at the time - in the future someone handling an incident or trying to fix a P1 bug on a Friday afternoon will thank you.