Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Feel your pain <3 You can tell it's been a few years now but I have worked at Big Corp Inc. before.

I know what it's like to ask someone in charge of 8k people to personally approve my server permission escalation even though he's never met me, doesn't know anything about the IT systems, has never visited the site I work at or probably even been in the country I reside.

Anyway, a good thing on this front now is that (speaking from Azure exp.), you can dump logs directly to blob storage (s3, whatever google call their data storage). Then you only need that permission.

As for the non-UTC servers... -_- but if it's a problem, you can always append the tz info to the log date format.



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..)


what 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.


Right - 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


I 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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: