DEV Community: calculatorspan

Why Your Date Shows 1970: Unix Timestamps in Seconds vs Milliseconds

calculatorspan — Wed, 30 Sep 2026 17:01:12 +0000

Why Your Date Shows 1970: Unix Timestamps in Seconds vs Milliseconds

You fetch a timestamp from an API, pass it to new Date(), and the screen says January 20, 1970.

Or you get the opposite: a date in the year 55,840.

Nothing is wrong with your date library. You've met the most common timestamp bug there is: mixing up seconds and milliseconds.

What a Unix timestamp is

Need to decode a timestamp right now? Paste it into this free
Unix Timestamp Converter
and it shows the date for both seconds and milliseconds.

A Unix timestamp counts the time elapsed since 1970-01-01 00:00:00 UTC (the "epoch"). The catch is that different systems count in different units.

Unit Example Digits (today)
Seconds 1700000000 10
Milliseconds 1700000000000 13
Microseconds 1700000000000000 16
Nanoseconds 1700000000000000000 19

All four of these describe the same moment: 2023-11-14 22:13:20 UTC.

Who uses which unit
Seconds: Python's time.time() (as a float), PHP's time(), Go's time.Now().Unix(), most databases and JWT exp/iat claims, and many REST APIs
Milliseconds: JavaScript's Date.now() and new Date(ms), Java's System.currentTimeMillis(), and Go's UnixMilli()
Nanoseconds: Go's UnixNano() and many logging and tracing systems

The bug appears when a backend sends seconds and a frontend expects milliseconds, or the other way round.

Bug 1: seconds treated as milliseconds (you get 1970)

JavaScript's Date takes milliseconds. If you pass it seconds, it thinks only about 19 days have passed since the epoch:

js
const ts = 1700000000; // seconds, from an API

new Date(ts).toISOString();
// "1970-01-20T16:13:20.000Z" (wrong)

new Date(ts * 1000).toISOString();
// "2023-11-14T22:13:20.000Z" (correct)

Fix: multiply by 1000.

Bug 2: milliseconds treated as seconds (you get year 55,840)

Now the reverse. You have milliseconds, but the code multiplies by 1000 anyway:

js
const ts = 1700000000000; // milliseconds

new Date(ts * 1000).toISOString();
// "+055840-11-08T22:13:20.000Z" (wrong)

In Python, the same mistake raises an error instead of quietly giving a wrong date:

python
from datetime import datetime, timezone

datetime.fromtimestamp(1700000000000, tz=timezone.utc)

ValueError: year 55840 is out of range

datetime.fromtimestamp(1700000000000 / 1000, tz=timezone.utc)

2023-11-14 22:13:20+00:00 (correct)

Fix: divide by 1000 (Python, like most languages, expects seconds).

A quick way to tell which unit you have
If you just want to check one value without writing code, the
Unix Timestamp Converter
handles seconds and milliseconds.

Count the digits. For dates in the present day:

10 digits means seconds
13 digits means milliseconds

You can also guard against it in code:

js
function toDate(ts) {
// Below ~1e11 it's almost certainly seconds (1e11 s is the year 5138).
// Above it, treat as milliseconds (1e11 ms is March 1973).
return new Date(Math.abs(ts) < 1e11 ? ts * 1000 : ts);
}

toDate(1700000000); // 2023-11-14T22:13:20.000Z
toDate(1700000000000); // 2023-11-14T22:13:20.000Z

This heuristic is handy for display code and quick scripts. It fails for millisecond timestamps before March 1973, so in production code it's better to know the unit from the API docs and convert explicitly.

Getting the current timestamp in each unit
js
// JavaScript
Date.now(); // milliseconds
Math.floor(Date.now() / 1000); // seconds
python

Python

import time
time.time() # seconds (float)
int(time.time() * 1000) # milliseconds
go
// Go
time.Now().Unix() // seconds
time.Now().UnixMilli() // milliseconds
time.Now().UnixNano() // nanoseconds
Habits that prevent this bug
Name the unit in the field. Use createdAtMs or expiresAtSec instead of timestamp.
Document the unit in your API spec, and prefer one unit across the whole API.
Convert at the boundary. Parse incoming timestamps into a proper date type as soon as they enter your code, and avoid passing raw numbers around.
Store and compute in UTC. Convert to local time only when displaying.
Watch for 32-bit seconds. A signed 32-bit seconds value overflows on 2038-01-19 03:14:07 UTC. Use 64-bit integers for timestamps in new code.
A quick sanity check when you're debugging

When a value looks suspicious, paste it into a converter and see which unit gives a sensible date. I built a free Unix Timestamp Converter for exactly this, and there's a Time Zone Converter for when the date is right but the hour looks off.

Wrap-up
Unix timestamps count from 1970-01-01 UTC, but the unit varies.
1970 in your output usually means you passed seconds where milliseconds were expected.
A date in the year 55,000 usually means you passed milliseconds where seconds were expected.
Name your units, document them, and convert at the edges of your system.

What's the strangest timestamp bug you've run into? Share it in the comments.

Why "What Time Is It in 8 Hours?" Is Harder Than It Looks

calculatorspan — Thu, 27 Aug 2026 11:15:26 +0000

A deployment window opens in 4 hours. A cron job fires every 72 hours. A client says "we need this by end of day" from a different time zone. And suddenly simple time math becomes surprisingly annoying.

Adding hours to a current time sounds trivial. It isn't.

Where Manual Time Math Breaks

Midnight crossings
It's 9:45 PM. Add 6 hours. You cross midnight, the date changes, and one small arithmetic slip gives you the wrong timestamp entirely.

Month-end rollovers
Add 72 hours to January 30. You land in February. Most people count wrong.

Daylight saving transitions
Add 24 hours near a DST boundary and you might land an hour off — silently.

Mixed hours and minutes
"Add 2 hours and 45 minutes to now" requires converting to decimals first if your tool only accepts whole numbers.

How the Calculation Actually Works

A proper hours-from-now calculator does this under the hood:

javascript
function hoursFromNow(hours, minutes = 0, seconds = 0) {
const now = new Date();
const totalMs = (hours * 3600 + minutes * 60 + seconds) * 1000;
const future = new Date(now.getTime() + totalMs);
return future;
}

// Example
const result = hoursFromNow(72);
console.log(result.toLocaleString());
// Handles date rollovers, DST, and month boundaries automatically

The key insight: work in milliseconds, not hours. Let the Date object handle all the edge cases — month lengths, leap years, DST — instead of doing it manually.

Common Use Cases Developers Actually Hit
Scenario Hours Offset
Deployment monitoring window 4–8 hours
Cache expiry check 24 hours
Two-day SLA deadline 48 hours
Legal response window 72 hours
One week reminder 168 hours
The Tool

If you just need to calculate this without writing code:
🔗 calculatorspan.com/hours-from-now-calculator

It handles midnight crossings, month rollovers, DST, and mixed hours + minutes in one step. Free, no signup, works on any device.

Key Takeaway

Time math is one of those things that feels simple until production breaks at 11:58 PM on January 31st during a DST transition.

Always use millisecond arithmetic. Always let the Date object handle rollovers. And when you just need a quick answer — use a calculator.

What's the worst time-related bug you've hit in production? Drop it in the comments.

Calculating Lead Time in Working Days

calculatorspan — Wed, 12 Aug 2026 18:21:56 +0000

Lead time is one of those metrics that sounds dead simple until you try to track it consistently across a real project. Then it gets messy fast.

I've seen teams calculate it three different ways in the same sprint retrospective and argue about which number was correct. They were all correct — they were just measuring different things.

So let me break down exactly what lead time is, how to calculate it, and where teams go wrong.

What Lead Time Actually Measures

Lead time is the total time from the moment a request is created to the moment it's delivered. That's it. From "we need this" to "it's done."

It does not start when your team picks up the work. It does not start when development begins. It starts the second the request enters your system — whether that's a Jira ticket, a GitHub issue, a Slack message, or a sticky note on a whiteboard.

This is where most teams get confused. They're measuring cycle time and calling it lead time.

Lead time = time from request created → work delivered
Cycle time = time from work started → work delivered

Cycle time is always shorter than lead time. If you're using cycle time to make promises to stakeholders, you're going to miss deadlines.

The Formula
Lead Time = Delivery Date - Request Date

That's the whole formula. The complexity comes from what you count inside those boundaries.

Working Days vs Calendar Days

This is the first decision you need to make. Do you measure in calendar days or working days?

Calendar days are simpler to track but misleading. A request created Friday afternoon and delivered Monday morning looks like 3 days on a calendar, but your team worked on it for maybe 4 hours.

Working days give you a more accurate picture of actual team capacity. If your team works Monday through Friday, a lead time of 10 working days means two full work weeks which is a meaningful number you can actually plan around.

For most dev teams, working days is the right choice. Use a lead time calculator that handles working days automatically if you don't want to write the logic yourself.

A Practical Example

Say a feature request comes in on Monday January 6th. Your team ships it on Friday January 17th.

Calendar days: 11
Working days: 10

If January 13th was a public holiday, working days drops to 9.

Same delivery, different numbers depending on how you count. Pick one method and stick to it across your whole team the consistency matters more than which method you choose.
Where Teams Go Wrong
Ignoring queue time

The biggest mistake I see is teams only tracking active work time. A ticket that sat in the backlog for 3 weeks before anyone touched it had lead time from the day it was created — not from the day it got assigned.

If your lead times look suspiciously short, check whether you're accidentally measuring cycle time.

Inconsistent start points

Some teams start the clock when a ticket is created. Others start it when it's groomed and added to a sprint. Others start it when it's assigned. Pick one definition, document it, and enforce it.
Not segmenting by work type

A bug fix and a new feature have completely different lead time profiles. If you average them together, the number is meaningless for planning. Track lead time separately for bugs, features, tech debt, and incidents.

What's a Good Lead Time?

It depends entirely on your team and product type. There's no universal benchmark.

That said, here's a rough frame based on what I've seen across different team setups:

Team Type Typical Lead Time
High-performing DevOps teams Less than 1 day
Healthy product teams 1–7 working days
Average enterprise teams 2–4 weeks
Teams with process problems 1–3 months

The DORA metrics research (from the State of DevOps report) uses lead time for changes as one of its four key metrics. Elite performers get changes into production in less than an hour. That's a different measurement context — they're tracking code commit to production, not ticket creation to delivery — but it gives you a sense of what's possible.

Reducing Lead Time

Once you're measuring accurately, reducing lead time usually comes down to three levers:

Reduce queue time. Work sitting in a backlog waiting to be picked up is the biggest lead time killer. Limit work in progress so tickets move faster once they're created.

Reduce handoff friction. Every time work moves between people or teams, it waits. Design reviews, QA, code review, deployment approvals — each one adds days. Streamline the handoffs you can.

Smaller batch sizes. Big features have long lead times. Break them into smaller deliverables that can ship independently. A feature split into five smaller releases will almost always have a lower average lead time than one big release.

Tracking It Without Overthinking

You don't need a fancy tool to start. A simple spreadsheet with ticket ID, created date, delivered date, and a working days formula gets you 80% of the value.

If you want to calculate working days without writing the formula yourself, there are free tools that handle it — including one at CalculatorSpan that lets you factor in custom holidays.

The important thing is to start tracking it consistently. Even rough data collected over two or three sprints will show you patterns you didn't know existed.

Lead time is one of the most honest metrics a dev team can track. It doesn't care about velocity points or story estimates — it just measures the gap between what was asked for and when it arrived. That gap is worth knowing.

If you found this useful, I write about practical productivity tools and calculators at CalculatorSpan.com.

How to Calculate Lead Time in Project Management (With a Free Calculator)

calculatorspan — Fri, 07 Aug 2026 15:41:01 +0000

Lead time sounds simple. It's just the time between starting something and finishing it, right?

Kind of. But if you've ever missed a deadline because your estimate was off by two days, you already know the gap between "sounds simple" and "actually useful."

Let me break this down properly
what lead time means, how to calculate it, and where most teams go wrong.

What Is Lead Time in Project Management?

Lead time is the total time from when a request or task is initiated to when it's completed and delivered.

It's not just the work time. It includes:

Waiting time before work starts
Active processing time
Review and approval time
Any delays in between

That's the full picture. And that full picture is what you need to plan accurately.

The Basic Lead Time Formula
Lead Time = Delivery Date Order/Request Date

Simple example: If a client requests a deliverable on Monday and you deliver it on Friday, your lead time is 4 days.

But real projects have more moving parts. Here's a more complete version:

Lead Time = Pre-processing Time + Processing Time + Post-processing Time
Pre-processing — time before actual work begins (waiting, queuing, planning)
Processing active work time
Post-processing — review, QA, approval, handoff
A Real Example

Say you're managing a content production workflow:

Client brief received: Monday 9 AM
Writer starts work: Tuesday 10 AM (1 day pre-processing)
Writing completed: Wednesday 5 PM (1.5 days processing)
Review + approval: Thursday 3 PM (0.5 days post-processing)

Total Lead Time = 3 days + 6 hours

If you only counted writing time, you'd have planned for 1.5 days and missed the actual delivery window by double.

Lead Time vs. Cycle Time Don't Mix These Up

This trips up a lot of project managers.

Term What It Measures
Lead Time Full time from request to delivery
Cycle Time Time from when work actually starts to delivery

Cycle time is always shorter than or equal to lead time. If your cycle time is great but lead time is high, your bottleneck is in the waiting not the work itself.

How to Use Lead Time to Improve Planning

Once you're tracking lead time consistently, you can:

Set realistic deadlines base them on historical averages, not optimistic estimates
Identify bottlenecks high pre-processing time means your intake or prioritization process needs work
Improve client communication tell clients actual lead times, not best-case times
Reduce waste every day of unnecessary waiting is a day of delayed delivery

In my experience, most teams underestimate lead time by 30–40% because they only account for active work time.

Calculate It Without the Headache

Doing this manually gets tedious fast especially across multiple tasks or team members.

I built a free Lead Time Calculator on calculatorspan.com that handles the math instantly. Plug in your start date, end date, and working hours it gives you the exact lead time breakdown.

👉 Try the Lead Time Calculator calculatorspan.com

No signup. No fluff. Just the number you need.

Quick Tips Before You Go
Always measure lead time in working days, not calendar days, for accuracy
Track lead time per task type design tasks and dev tasks have different baselines
Review your average lead time monthly and look for trends
If lead time is increasing over time, your team capacity or intake process has a problem

Lead time is one of those metrics that looks basic but reveals a lot when you actually start tracking it. Start measuring it on your next project even informally and you'll immediately make better commitments.