Timestamp Converter for API Log Debugging

A timestamp converter is useful when an API log, database field, browser event, or webhook payload shows a time value that looks correct in one place and wrong in another. The problem is often not the timestamp itself. It is the unit, timezone, display format, or system clock used to interpret it.

Use the Timestamp Converter to inspect the value before changing code. A quick conversion can show whether you are looking at seconds, milliseconds, UTC time, or a local display problem.

Seconds and milliseconds are the first check

Unix timestamps often appear in seconds, but JavaScript time APIs commonly use milliseconds. Confusing the two can move a date by decades.

A practical first check is simple:

Value shape	Likely unit	What to verify
10 digits	seconds	Common Unix timestamp format
13 digits	milliseconds	Common JavaScript timestamp format
Very small value	relative time or duration	Not an absolute timestamp
String date	formatted time	Need parser and timezone context

Do not trim digits until you know the producer. If a backend sends milliseconds but a client treats it as seconds, the UI will show a date far in the future. If a backend sends seconds but a client treats it as milliseconds, the UI may show a date near 1970.

UTC and local time can both be correct

A timestamp represents a point in time. The display may change depending on timezone. A log stored in UTC can look different when rendered in a local browser timezone, but it may still point to the same moment.

When debugging, compare:

• raw timestamp value;
• UTC display;
• local browser display;
• server timezone;
• database timezone;
• user timezone if the app stores one.

Avoid fixing a timezone display issue by changing stored timestamps blindly. The safer fix is usually to keep storage consistent and adjust display rules intentionally.

API logs need the original payload

If an API call failed because of an expiry time, scheduled time, or event time, inspect the exact payload. A formatted value in a dashboard may not be the same value sent over the wire.

Use JSON Formatter first when the timestamp appears inside JSON. Confirm the field name and value, then convert the timestamp. This prevents a common mistake: converting the wrong field or a transformed display value.

Useful fields to check include:

• created_at;
• updated_at;
• expires_at;
• exp;
• iat;
• nbf;
• scheduled_for;
• event_time.

Expiration bugs are often boundary bugs

A token, invite link, webhook replay window, or temporary download link may fail near a boundary. The timestamp might be valid, but the comparison rule may be strict.

Check whether the system uses:

• less than versus less than or equal;
• server time versus client time;
• rounding to seconds;
• truncation from milliseconds;
• grace periods;
• clock skew tolerance.

If a value fails only near the deadline, do not assume the converter is wrong. The comparison logic may be different from the display logic.

Database and browser displays can disagree

Databases, ORMs, APIs, and browsers may serialize time differently. One layer may store UTC, another may return ISO strings, and the browser may render the value in local time.

When the same event appears different across systems, write a small comparison table:

Layer	Value	Timezone / unit
API payload	raw field	seconds, milliseconds, or ISO
Database	stored field	UTC or configured timezone
Backend log	formatted output	server timezone
Browser UI	rendered value	user local timezone

This table often reveals the real mismatch faster than changing date formatting code repeatedly.

A safer timestamp debugging workflow

1. Copy the exact value from the API payload or log.
2. Identify whether it is seconds, milliseconds, or a formatted string.
3. Convert to UTC first.
4. Compare local display only after UTC is understood.
5. Check the producer system and consumer system separately.
6. Look for rounding, truncation, and boundary comparisons.
7. Add tests with values just before and after the critical time.

If the timestamp appears in a numeric format you do not recognize, the Number Base Converter can help rule out base conversion confusion, but most API time bugs are seconds, milliseconds, or timezone issues.

FAQ

Why is my timestamp off by several hours?

It is probably a timezone display issue. Compare the UTC value with the local browser display before changing stored data.

Why is my timestamp off by decades?

You may be mixing seconds and milliseconds. A 10-digit Unix timestamp is usually seconds; a 13-digit JavaScript timestamp is usually milliseconds.

Should APIs store local time?

Most systems store a consistent absolute time, commonly UTC, then render local time for users. The right choice depends on the product, but mixing storage rules is risky.

How do I debug exp or expires_at fields?

Convert the raw value, compare it with server time, then check the exact comparison rule and any clock skew tolerance.