Log::Entry timestamp uses Time.local

[Blacksmoke16]

Does it make sense for the timestamp to not be UTC? I would think UTC would make more sense, especially when trying to consume the logs generated by two applications in two different regions.

Originally posted by @Blacksmoke16 in #9570 (comment)

[asterite]

I don't think so. If I develop an app in the US I'll consume the logs in the US. Maybe there are remote workers, they'll have to translate the time. But I'd say that's the exception, not the norm. Local times are always more intuitive.

[Blacksmoke16]

Right, but if you have servers on east and west coast, looking at the logs in the console you would have interleaved logs with different times, even tho they happened at the same time.

If anything, IMO, it would make more sense to have the source of truth (the Log::Entry) use something a bit more universal and leave how to actually render the time to the formatter.

[asterite]

Yes, but if you have servers on east and west coast, then everyone will have to translate from UTC to their time. So if at least a chunk of the team gets local time I think it's better.

[asterite]

you would have interleaved logs with different times

I don't think so...? The app will only run in one machine with one local time.

[Blacksmoke16]

I don't think so...? The app will only run in one machine with one local time.

It would if you have two machines, one on each coast, running two instances of the same application. Such as for regional load balancing; since each sever would be reporting its own local time.

IMO the mental overhead of converting from a standardized time to your local time is much less than converting from some arbitrary local time into your local time.

Also lets not forget that this isn't scoped solely to IO related things. Since the Log::Entry is local, if you were to push these logs to like sentry, they would still be local times. Which might not be ideal if that application handles converting the timestamps to your local time for you anyway.

[asterite]

I think it makes sense. Maybe it depends on the log backend. If the log understands timezones (I think it should) they it could present entries in the user's timezone. I'll let others comment on this because I ran out of ideas :-)

[jwoertink]

If the machine's local time is set to UTC, would Time.local return UTC time? I've actually had a rails app that's been deployed in different time zones, but I've always configured the machines to be UTC, and told rails to use UTC. In that case it didn't matter if I ssh in to a west cost or east coast box, it was always UTC.

[straight-shoota]

If the machine's local time is set to UTC, would Time.local return UTC time?

Yeah, I guess that makes sense. If you want your logs in UTC, you could set local timezone to UTC. That would obviously affect all other parts of the application as well. But I suppose if you have an application running in different time zones, you would need to have some dedicated mechanism for presenting time in a user's local time zone.

Also, Time.local is the internal default value for Log::Entry. When a log message is sent to any kind of backend, a formatter makes sure to present the log data in a proper format. So you could use a formatter that displays the timestamp in UTC if you want your export data to be in UTC.

[Daniel-Worrall]

Can this at least be configurable?

[straight-shoota]

I don't think there needs to be explicit configuration for this. You can configure TZ/Time::Location.local. And with #9570 you can create a custom Log::Entry instance with whatever time value you want.

[bcardiff]

I think we can move the default value to a class method. That way it can be overridden easily for the whole app.

[Blacksmoke16]

When a log message is sent to any kind of backend, a formatter makes sure to present the log data in a proper format. So you could use a formatter that displays the timestamp in UTC if you want your export data to be in UTC.

Yes, I guess my thinking was that the more common option would be UTC based backends. I.e. have the default be UTC, then have the STDOUT related logger convert that to local time.

[straight-shoota]

@Blacksmoke16 Yeah, that should also work. It's either one or the other. IMO Time.local has the benefit of presenting time in easy-to-comprehend-format by default (for example in p log_entry.timestamp).