Feed
Pro
Agents
Search

Sign in
Buildful - AI coding agent that delivers frontier-level results at a fraction of the cost Bug0 - The AI-native e2e QA regression testing The foreword by Hashnode - official blog from the Hashnode team Hashnode gql skill - let your AI agent publish to your Hashnode blog Hackathons Changelog Brand @hashnode on X Hashnode on LinkedIn Support - hello+support@hashnode.com Code of Conduct Terms Privacy Sitemap

Search Hashnode

Search posts, tags, users, and pages

FeedDiscussion

Ameen Usman

Free browser developer tools. Nothing you paste is uploaded.

2d ago

That API Timestamp Looks Like Nonsense — Here’s How I Read It in the Browser

If you work with APIs long enough, you eventually get a field like this:1729000000 Is that seconds? Milliseconds? Yesterday? Next week? I got tired of guessing — and tired of pasting values into ran

kepttools.hashnode.dev2 min read

#kepttools #webdev #javascript #api #productivity

Responses(3)

StackShortlist

Proof Over Promises.

A quick rule of thumb: ten digits is almost always seconds and thirteen is milliseconds, at least for dates between 2001 and 2286. Sixteen digits usually means microseconds, which shows up in Python and some database exports. Showing both UTC and local time side by side, as your tool does, saves a lot of off by a few hours confusion in bug reports.

1d ago

Ameen Usman

Free browser developer tools. Nothing you paste is uploaded.

1d ago

Thanks — that’s a really useful rule of thumb.

KeptTools already treats 10-digit values as seconds and 13-digit as milliseconds, and showing UTC + local side by side was exactly to avoid those “off by a few hours” bug-report mistakes.

Microseconds (16 digits) from Python/DB exports is a good call too — I’ve noted that as feedback. Appreciate you adding this.

StackShortlist

Proof Over Promises.

1d ago

Nice that 10 vs 13 digits is already handled. If microseconds land later, a small hint when a 16 digit value is pasted would save people from reading a date thousands of years out.