UTC DateTime timestamps in Logger in Elixir 2.0?

[Lau Taarnskov]

There are some problems with the datetime tuples from Logger today:

1) Ecto uses microseconds in the fouth sub-element of the time element of the tuple. Logger uses microseconds. I was surprised by this inconsistency. The two kinds of tuples look exactly the same and both Logger and Ecto are "official" Elixir pieces of software.

2) You cannot be sure what timezone the datetime is in. Because by default Logger uses the localtime (which could be anything). And even if you configure logger to use UTC, the datetime tuples do not contain this information.

In Elixir 2.0 could timestamps be UTC only?

How about using DateTime structs (that will come in Elixir 1.3) instead of the current datetime tuples?
That way you know that the timestamp is in UTC just by looking at the data. And more importantly functions
the receive the timestamps as arguments can use this timezone data.

[José Valim]

The plan is to migrate Ecto to use the new calendar types considerably sooner than we will be able to change Logger. So at least the duality should be gone. Also, fwiw, Ecto is not really "official". It is in the elixir-lang organization but we are planning to move it elsewhere.

>  You cannot be sure what timezone the datetime is in. Because by default Logger uses the localtime

There is a flag that can set the timestamp to UTC. The reason I don't want to default to UTC is because that would be a very confusing behaviour for development. One option is to start including this flag in the generated config/config.exs, so folks realize they likely want to set it to true in production.

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
You received this message because you are subscribed to the Google Groups "elixir-lang-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/665b50f8-af2c-4654-ba93-988370fe5851%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Lau Taarnskov]

 

There is a flag that can set the timestamp to UTC. The reason I don't want to default to UTC is because that would be a very confusing behaviour for development. One option is to start including this flag in the generated config/config.exs, so folks realize they likely want to set it to true in production.

I can see that it can be confusing to have logs in development that you don’t know what timezone it belongs to. E.g. you develop something, then you go on a trip, where the timezone is different. In your logs you then have time stamps, but you are not sure which time zone they belong to. So you don’t know exactly when something happened. Or instead of changing the timezone setting on your computer you change your setting in config/config.exs for using UTC with logger or not. Again, in the saved logging data you don’t know which it is.

Also what if you have one config UTC in production and another for “local time” on a development machine? You might be looking at local time one second, and UTC the next without being able to tell which is which.
 
If they were DateTime structs in UTC then you have the information right there in front of you. Instead of printing e.g. "16:35:42.938", the default could be “3 May 16:35:42.938 UTC”. Any developer used to checking timestamps on a server running UTC is used to reading UTC timestamps anyway. And with the information right there on the screen is no need to figure out if it is in UTC or not.

Logging tools could make use of this information too. For tools to compare logging timestamps to other timestamps, it needs to know what the timestamps are in UTC. Today, the only way to do this without over complicated code is to write in the documentation “put this in your settings to set logger to use UTC or set your local time to UTC and hope it doesn't change”.

In 1998 NASA launched a spacecraft to Mars. They also had a system outputting numbers. The software relied on the document saying that the numbers were to be in metric units. Someone didn’t follow the document. The spacecraft disintegrated. https://en.wikipedia.org/wiki/Mars_Climate_Orbiter

When you have the UTC offset data right there, as you do with a DateTime struct, it gives an assurance that you don’t have when relying on people reading and following documentation. Pattern matching against a time_zone field is a lot more reliable.

- Lau