4 ms·
The problem that the above user had was that the logs were already written without tz info, so they had no way to know. Assuming it was set to the machine's tz
by jagraff 6y ago
The problem that the above user had was that the logs were already written without tz info, so they had no way to know. Assuming it was set to the machine's tz producing the logs, you could probably figure out the tz from the machine's ip address (assuming that's produced in the logs as well..)
- mgkimsal 6y agowhat I learned was that the logs are timestamped to whatever machine they're on, wherever it is. The servers in London - GMT. The servers in west coast - Pacfic time. Servers in DC - Eastern time. Not ideal.
- jagraff 6y agoRight - assuming the server IP, or at least some other network identifying factor, is in the log, you could write some sort of regex to parse the logs and identify the correct time. Of course, that depends on someone being able to actually parse the logs with your regex
- perl4ever 6y agoI once found a solution to determining the timezone when it wasn't available - a field with only a date was unnecessarily and incorrectly converted to UT, meaning that the zone could be derived from the offset from midnight and applied to other fields. If enough things are screwed up, you can possibly find the solution to one issue in another.