Comment by EdwardDiego | Hacker News Reader

Comment by EdwardDiego | Hacker News Reader

In a very globalised world, where your developers can be working in a multitude of countries, I've found that the only sane thing to do is a) run all your boxes with a TZ of Zulu and b) the only date format allowed in logs is RFC-3339.

Sure, you can format datetimes in localised formats for end users, but standardising on UTC+0 and RFC-3339 for programming and maintenance purposes just prevents so much confusion and hassle.

Not that I've ever had to spend a day trying to troubleshoot a bug that was alerted by our monitoring system at 2020-11-09T09:11:05Z (as it was defaulting to UTC), but the relevant logs were timestamped at 10:11:05 09/11/2020 (I only wished they'd used the normal German period separators in the date to give me a clue) because of course your German colleagues want their timestamps in German format and defaulting to CET...

When you have colleagues in Europe, Oceania, and distributed from coast to coast in the US, doing everything in UTC means everyone only has to do one mental conversion from their local timezone to UTC, as opposed to trying to remember if they're in LA or New York, or if they're in Mountain Time, if they're in the parts of the US that are Mountain Time but don't do daylight savings.

> Not that I've ever had to spend a day trying to troubleshoot a bug that was alerted by our monitoring system at 2020-11-09T09:11:05Z (as it was defaulting to UTC), but the relevant logs were timestamped at 10:11:05 09/11/2020

It gets even more fun when such events happen during the switch between daylight saving time (like CEST) and standard time (like CET).

When I worked closely with Germans there was a special time of year where our daylight savings changes overlapped, so for a few weeks we'd have a 10 hour time difference, then an 11 hour time difference, then 12. We tried to minimise meetings during that period, as someone always got the timing wrong.

Ah, daylight savings.

I have no end of complaints about cloudwatch but them automatically parsing datetimes and presenting them in my browser's timezone is a godsend.

I'm okay with that when the tool makes it clear it's done so, and it's easy to switch to the original TZ.

(I always set CW back to UTC, for consistency)

CloudWatch at least lets you choose in which timezone to display datetimes. Other AWS services don't let you choose and don't even show in which timezone they display datetimes, which is somewhat infuriating to me, when I'm in a hurry anyway and suddenly have to wonder which timezone the shown dates are in.

I also remember that AWS used to display some datetimes in Pacific Standard Time, which is completely useless to somebody outside the US, however I haven't seen that in a while anymore.

Similar to the global language switch I wish the AWS Management Console would allow setting in which timezone to display datetimes globally as well.

Or zero mental conversions because it's trivial to write a simple script that ingests RFC-3339 and spits it out in your local time.

"2020-11-09T09:11:05Z" uniquely identifies a point in time. "10:11:05 09/11/2020" is some time 11 minutes past the hour on either September 11th or November 9th. It doesn't identify anything.

Edit: Or 41 minutes past the hour.

The first format also makes it easy to do counts of # of entries within November 2020. The Second makes life considerably more difficult (not impossible though).

The second format does make life impossible because it is not a timestamp (without context information).

I did always love a quick and easy `WHERE ts like '2020-09%'` when flinging data into Athena or Spark SQL etc. and treating the column as text for ease of loading.

Reply on news.ycombinator.com