4 ms·
This is not exactly the same thing, but for the love of god, if you have a monitoring or logging product, make the date and time zone visible wherever time is d
by sleepydog 5y ago
This is not exactly the same thing, but for the love of god, if you have a monitoring or logging product, make the date and time zone visible wherever time is displayed. I cannot tell you how many times I've been sent screenshots of graphs, showing some catastrophic scenario at, say, 08:43, with no idea of what time zone the graphs are using, or what day the graph is showing.
- 10000truths 5y agoI prefer the use of Unix timestamps. Easier to filter with standard Unix tools, and if I really need formatted date+time in my output, I can always use awk.
- simion314 5y agoI don like it, say I open a database table and search for some events , then look at the created_at column and see a timestamp, so now I need to copy paste timestamps into a webpage and convert it to human readable time to then notice is 5 years old and not what i am looking for. What are you doing in this case?(in case you worked with database logs), export to csv and then do it with unix tools?
- 8n4vidtmkvmk 5y agodepending on the sql dialect, you can convert it in sql. or even add a virtual column with the conversion for your convenience
- berkes 5y agoI used to prefer unix timestamps too. But I Saw The Light. For one: those standard Unix tools can convert from date/time values to timestamps just as easy. Arguably easier. And a timestamp is merely an Int, so many languages, databases, APIs and so on, lack ergonomic methods to convert timestamps to datetimes. But have easy ways to do the reverse. It's almost always easier to convert dates, times or datetimes to timestamp ints (or floats) than to convert an int or float to a date, datetime or time. A timestamp.toString() is unfamiliar to humans, a datetime.toString() is not. The list of small benefits in favor of actual date or time types just goes on.
- kristopolous 5y agomake everything UTC, people. It'll make your life way easier. Try it out.
- Too 5y agoInternally yes, this is a no brainer. However in log files that are often read directly by humans, who want to see things in local time, it can become a balance and you might need to fight some admins for it. A proper structural logging system solves this, but log files on disk and other ad-hoc diy logs is still extremely common to see.
- guipsp 5y agoJust live in GMT+0. Easy!
- alephnil 5y agoI have sometimes put my computer in the Iceland time zone for that reason when using dual boot with Linux, since Linux prefer to run UTC on the clock, and the Iceland time zone is UTC+0 with no daylight saving time. Making windows believe it is in Iceland make sure it does not mess up the clock. Though it is possible to set windows to UTC too with the same effect.
- gpderetta 5y agoEspecially in log files I want to see UTC. When you have servers all around the world, I do not want to figure out what timezone was the specific server running in nor I want to convert between timezones when comparing logs of different servers.
- barrkel 5y agoOn-disk logs should use ISO-8601 in UTC, ideally first thing on the line. That way you can merge them from different sources and sort them to help figure out interactions and causality. There might be clock drift from different sources but that's a much smaller problem than trying to eyeball multiple different logs concurrently, or write ad-hoc scripts to enable merging.
- ruuda 5y agoYeah, this is also happens in code. The solutions are the same, either use a type that is unambiguous (`timestamptz` in Postgres, `datetime` in Python with `.tzinfo is not None`, `DateTimeOffset` in .NET, `UTCTime` in Haskell etc.), or if you have to use naive datetimes, put the time zone in the name and call it `datetime_utc`.
- twistedpair 5y agoIf it was a Google product, it's implicitly Pacific Standard Time.