Developer & system utilities
Server log translator
Read logs in the time zone you think in. Paste lines with ISO or epoch timestamps and see each one converted to your local clock — all in the browser, nothing uploaded.
| Log line | Your local time |
|---|---|
[2026-07-24T13:05:22Z] INFO request handled in 42ms | 1:05 PM Fri, Jul 24, 2026 |
1784899686 WARN cache miss for key user:42 | 1:28 PM Fri, Jul 24, 2026 |
192.168.1.10 - - [2026-07-24 09:15:00] "GET /api" 200 | 9:15 AM Fri, Jul 24, 2026 |
Detects ISO 8601 timestamps and 10- or 13-digit Unix epochs, line by line, and converts the first one it finds to your local zone.
How to use the server log translator
Paste a log line
Drop in a raw line or just the timestamp. Common formats are recognised — ISO 8601, epoch seconds and milliseconds, syslog and Apache-style stamps.
Set the source zone if it is missing
Plenty of log formats omit the zone entirely. If the stamp has no offset, tell the tool which zone the machine was in, or the conversion is a guess.
Read it in your own zone
You get the instant in your local time and in UTC, which is what you need to line the event up against a report or another system's logs.
Correlate across systems
Convert timestamps from each system to UTC and compare those. Comparing raw local stamps from differently configured hosts is how false causality gets established.
Reading timestamps across differently configured systems
Incident work is mostly correlation, and correlation across systems is where time zones do their real damage. An application server in UTC, a database in the company's local zone and a customer report in a third are all describing the same minute in three different notations. Comparing the raw strings produces confident, wrong conclusions about what caused what.
The worst offenders are formats that omit the zone. Classic syslog writes "Jul 25 14:30:01" with no year and no offset, so interpreting it requires knowing how the host was configured — and if that host has since been rebuilt, that knowledge may be gone. Anything you control should emit ISO 8601 with an explicit offset or a Z.
Clock skew compounds it. Even with zones handled correctly, hosts drift, and a few seconds of skew is enough to reorder events in a fast-moving incident. NTP or a cloud time service keeps machines within milliseconds; without one, ordering across hosts is not trustworthy at fine granularity.
The working rule is to convert everything to UTC first, then order, then convert once into local time for the write-up. Human-readable local times belong in the report, not in the analysis.
When you'd reach for it
Incident timelines
Build one ordered sequence from logs written by hosts in different zones.
Matching a customer report
Translate "it broke around 3pm" into the window to search in UTC logs.
Reading legacy logs
Interpret zone-less stamps from an older system with a known configuration.
Cross-referencing metrics
Line a log line up against a dashboard that renders in a different zone.
Audit and compliance
Establish exactly when an action occurred in an agreed reference zone.
Post-incident review
Convert the final timeline into readable local times for the write-up.
Questions & answers
- What timestamp formats are recognised?
- ISO 8601 / RFC 3339 timestamps and 10- or 13-digit Unix epochs. The first timestamp found on each line is converted.
- How are timestamps without a zone handled?
- Server logs usually record UTC, so by default a timestamp with no offset is treated as UTC. You can turn that off to treat it as your local time instead.
- Is my log data uploaded?
- No. Parsing and conversion happen entirely in your browser — nothing is sent to a server.