DEV Community: Muhammad Wasif

JavaScript Array Loops: for vs forEach vs map

Muhammad Wasif — Wed, 26 Aug 2026 12:54:49 +0000

Use map when you want a new array, filter when you want fewer items, for...of when you need to break or await, and a plain for loop only when you are looping over millions of items and have measured that it matters. forEach sits in an awkward middle: it reads nicely, but it cannot break and it silently ignores await — which makes it the wrong default more often than people realise.

Quick decision table

You want to...	Use	Why
Transform every item into something new	`map`	Returns a new array, same length
Keep only some items	`filter`	Returns a new, shorter array
Boil the array down to one value	`reduce`	Sum, total, grouped object
Stop early / `break`	`for...of`	`forEach` cannot be stopped
`await` something each time round	`for...of`	`forEach` does not wait
Just do a side effect (log, push, update DOM)	`for...of` or `forEach`	Both fine; `for...of` is safer
Squeeze out speed on a huge array	`for`	Measurably faster, but see the benchmark

forEach vs map

map builds and returns a new array. forEach returns undefined — it exists purely for side effects.

const nums = [1, 2, 3, 4, 5];

const doubled = nums.map(n => n * 2);
console.log(doubled);  // [2, 4, 6, 8, 10]
console.log(nums);     // [1, 2, 3, 4, 5]  ← original untouched

console.log(nums.forEach(n => n * 2));  // undefined

The practical rule: if you're not using the returned array, you shouldn't be using map. Calling map purely for side effects builds a whole array you then throw away, and it misleads the next reader into hunting for a result that never gets used.

You can't break out of forEach

A return inside the callback only ends that one call — the loop keeps going:

const nums = [1, 2, 3, 4, 5];

let visited = 0;
nums.forEach(n => {
  visited++;
  if (n > 3) return;   // looks like a break, isn't one
});
console.log(visited);  // 5 — every item was still visited

With for...of, break does what you expect:

let found = null;
for (const n of nums) {
  if (n > 3) { found = n; break; }
}
console.log(found);  // 4

If you only need to know whether something matches, find, some, every and includes all stop as soon as they have their answer.

The async bug

This is the one that costs real debugging hours:

async function withForEach(ids) {
  const results = [];
  ids.forEach(async (id) => {
    results.push(await fetchThing(id));   // runs later, too late
  });
  return results;   // []  ← empty, every time
}

It returns an empty array. No error, no warning — forEach fires off the promises, ignores all of them, and returns. Use for...of, which genuinely pauses at each await:

async function withForOf(ids) {
  const results = [];
  for (const id of ids) {
    results.push(await fetchThing(id));   // waits properly
  }
  return results;   // [1, 2, 3, 4, 5]
}

That runs the requests one after another. If they're independent and you want them concurrent, don't loop at all:

const results = await Promise.all(ids.map(id => fetchThing(id)));

for...of with await is sequential — use it when each step depends on the last, or when you're being gentle on a rate-limited API. Promise.all is concurrent and finishes as fast as the slowest request.

Getting the index

for (const [i, n] of nums.entries()) {
  console.log(i, n);   // 0 1 / 1 2 / 2 3 ...
}

nums.forEach((n, i) => console.log(i, n));
nums.map((n, i) => `${i}: ${n}`);

Is a for loop actually faster?

Yes — and far less often than people assume. Summing an array of 10 million numbers on Node v24:

Loop	Time
`for`	88 ms
`for...of`	577 ms
`forEach`	750 ms

So a classic for loop is roughly 8× faster than forEach at that size. That sounds dramatic until you scale it down: for an array of 1,000 items — which covers the overwhelming majority of real code — the same gap is well under a millisecond.

Treat these as a rough shape rather than a law; results shift with the engine, the version and what the callback does. Write the clearest loop first. Reach for a plain for when you've measured a real bottleneck, not because a benchmark article said it was faster.

The sparse array gotcha

const sparse = [1, , 3];   // note the missing middle item

let a = 0; sparse.forEach(() => a++);
let b = 0; for (const _ of sparse) b++;

console.log(a, b);   // 2 3

forEach (and map, and filter) skip the hole; for...of visits it as undefined. Rare, but genuinely confusing when it bites — two loops over the same array producing different counts.

A few things people ask

Should I use forEach or for...of?
Prefer for...of as your default for side effects. It supports break and continue, works correctly with await, and handles sparse arrays predictably. forEach is fine for short synchronous callbacks — just never when async is involved.

Does map change the original array?
No. It returns a new array and leaves the original alone, which is why it fits well with React state. Be aware the items aren't deep-copied though: if your array holds objects, both arrays point at the same objects.

What about for...in?
Avoid it for arrays. for...in loops over keys, gives you strings ("0", "1") rather than numbers, and includes inherited enumerable properties. It's meant for plain objects.

The short version: pick the loop that says what you mean. map announces "I'm building a new array", filter announces "I'm narrowing this down", and for...of announces "I'm doing something for each item, and I might stop or wait." Speed almost never decides it — clarity does.

Originally published at cybercodelab.online.

How to Convert a Unix Timestamp to a Date in JavaScript

Muhammad Wasif — Mon, 24 Aug 2026 16:34:21 +0000

To convert a Unix timestamp to a date in JavaScript, multiply it by 1000 and pass it to the Date constructor: new Date(timestamp * 1000). The multiplication is the whole trick — Unix timestamps count seconds since 1 January 1970, but JavaScript's Date counts milliseconds. Skip the * 1000 and your 2026 date silently becomes January 1970.

const timestamp = 1786000000;
const date = new Date(timestamp * 1000);

console.log(date.toISOString());
// "2026-08-06T07:06:40.000Z"

That's the answer. The rest of this post covers the parts that actually bite people: telling seconds from milliseconds, formatting the result for humans, and converting back the other way.

Why does my timestamp show 1970?

Because the value is in seconds and new Date() expects milliseconds. This is the single most common bug in timestamp code, and it fails quietly:

new Date(1786000000).toISOString();
// "1970-01-21T16:06:40.000Z"  ← wrong, forgot the * 1000

Twenty-one days after the epoch instead of the year 2026. No error, no warning — just a wrong date sitting in your database.

The reason is that the two worlds disagree on units. Unix time — used by C, Python, PHP, MySQL, most REST APIs and every server log file — counts seconds. The ECMAScript specification defines a JavaScript Date as a number of milliseconds since the same 1970 epoch, which is why Date.now() returns a 13-digit number. Anything crossing that boundary needs a factor of 1000.

Seconds or milliseconds? Count the digits

For any date in the current era the answer is unambiguous:

Digits	Unit	Example	Means
10	Seconds	`1786000000`	6 Aug 2026
13	Milliseconds	`1786000000000`	6 Aug 2026
16	Microseconds	`1786000000000000`	6 Aug 2026

Ten digits means seconds and needs the * 1000. Thirteen digits is already milliseconds — pass it straight to new Date(). If you're handling both (say, from two different APIs), normalise defensively:

function toDate(value) {
  const n = Number(value);
  // 13+ digits is already milliseconds
  return new Date(n < 1e11 ? n * 1000 : n);
}

The 1e11 threshold works because 100,000,000,000 seconds lands in the year 5138 — far beyond anything a real seconds-based timestamp will contain, and far below any millisecond timestamp from the last 50 years.

Formatting it for humans

new Date() returns a Date object, not text. The default output is machine-shaped:

const date = new Date(1786000000 * 1000);

date.toISOString();
// "2026-08-06T07:06:40.000Z"   ← always UTC, good for storage and APIs

date.toString();
// A long local-time string that varies by machine — avoid for output

For anything a person reads, use toLocaleString() with an explicit locale and time zone. Being explicit is what makes the output predictable instead of "whatever the server happens to be set to":

const date = new Date(1786000000 * 1000);

date.toLocaleString('en-GB', {
  timeZone: 'UTC',
  dateStyle: 'full',
  timeStyle: 'short',
});
// "Thursday, 6 August 2026 at 07:06"

date.toLocaleString('en-GB', {
  timeZone: 'Asia/Karachi',
  dateStyle: 'full',
  timeStyle: 'short',
});
// "Thursday, 6 August 2026 at 12:06"

date.toLocaleString('en-US', {
  timeZone: 'America/New_York',
  dateStyle: 'medium',
  timeStyle: 'short',
});
// "Aug 6, 2026, 3:06 AM"

One timestamp, three different wall-clock readings — because a timestamp is a single instant, and the time zone is applied only at display time. That's a feature, not a bug: store the number, format at the edge.

Going the other way

To produce a timestamp instead of consuming one, divide by 1000 and floor it:

// Current time as a Unix timestamp (seconds)
const now = Math.floor(Date.now() / 1000);

// A specific date as a Unix timestamp (seconds)
const ts = Math.floor(new Date('2026-08-06T07:06:40Z').getTime() / 1000);
// 1786000000

Two details worth getting right:

Use Math.floor(), not Math.round(). Rounding can push you a full second into the future, which breaks "not valid before" comparisons and JWT expiry checks.
Include the Z (or a +05:00 style offset) when parsing a date string. new Date('2026-08-06T07:06:40Z') is unambiguously UTC; new Date('2026-08-06 07:06:40') is interpreted in the browser's local zone, so identical code produces different timestamps on different machines.

Common mistakes, and the fixes

Mistake	What happens	Fix
`new Date(seconds)`	Date lands in Jan 1970	`new Date(seconds * 1000)`
`Date.now()` sent to a seconds-based API	Timestamp ~1000× too large	`Math.floor(Date.now() / 1000)`
Parsing `"2026-08-06 07:06:40"`	Result depends on the machine's zone	Use ISO format with `Z`
`Math.round()` when converting to seconds	Occasionally one second ahead	`Math.floor()`
Formatting with `toString()`	Output differs per server and browser	`toLocaleString()` with explicit `timeZone`
Storing formatted text in the database	Zone information is lost forever	Store the timestamp or a UTC ISO string

That last row is the one that costs the most later. Store the instant; format on the way out.

A live clock, same conversion

setInterval(() => {
  const seconds = Math.floor(Date.now() / 1000);
  const label = new Date(seconds * 1000).toLocaleTimeString('en-GB', {
    timeZone: 'UTC',
    hour12: false,
  });
  document.getElementById('clock').textContent = label;
}, 1000);

A few things people ask

Does new Date(timestamp * 1000) apply my local time zone?
No. The Date object stores a single UTC instant; the time zone appears only when you format it. toISOString() always prints UTC, while toLocaleString() uses the browser's zone unless you pass an explicit timeZone option.

Can JavaScript handle timestamps from before 1970?
Yes. Negative timestamps work normally: new Date(-86400 * 1000) returns 31 December 1969. JavaScript's Date spans roughly ±8.64 × 10¹⁵ milliseconds around 1970 — about 273,790 years in each direction. Anything outside that returns Invalid Date.

Is JavaScript affected by the Year 2038 problem?
No. The 2038 problem hits systems storing timestamps in a signed 32-bit integer, which overflows at 2147483647 seconds — 19 January 2038, 03:14:07 UTC. JavaScript stores time as a 64-bit float of milliseconds, so it sails past 2038. You can still receive a broken value from a 32-bit backend, so the fix belongs on that side.

The rule is short enough to memorise: seconds in Unix, milliseconds in JavaScript, * 1000 in between. Get that one factor right and the rest of the Date API stops being mysterious.

If you want to sanity-check a raw number from a log file or a JWT payload without opening a console, I keep a free Unix Timestamp Converter that shows the real date instantly.

Originally published at cybercodelab.online.

Why Does Unix Time Start on January 1, 1970?

Muhammad Wasif — Mon, 10 Aug 2026 09:05:34 +0000

Unix time starts on 1 January 1970 because that date was chosen as the "Unix epoch" — the zero point from which seconds are counted — by the engineers building Unix at Bell Labs in the early 1970s. It has no cosmic meaning; it was simply a convenient, recent round date, and counting seconds from a single fixed moment makes time math simple and free of time zones. Every timestamp you see, like 1786000000, is just "this many seconds after that 1970 zero point."

If you've ever wondered why computers seem obsessed with 1970 — why a broken date defaults to "1 Jan 1970" and why timestamps count from there — this is the story. You can see the current count ticking live, or convert any timestamp to a real date, with our free Unix Timestamp Converter.

The short history: Bell Labs, early 1970s

Unix was created at Bell Labs starting around 1969 by Ken Thompson, Dennis Ritchie and their colleagues. Early versions needed a way to store time as a simple number, so they picked a starting point — an epoch — and counted forward from it.

The first choice wasn't even 1970. Early Unix measured time in sixtieths of a second (matching the electrical grid's 60 Hz) and used an epoch of 1 January 1971. The problem: at 60 ticks per second, a 32-bit counter overflows in only about 2.5 years — the clock would run out almost immediately. So the team made two changes: they switched to counting whole seconds instead of sixtieths, and they moved the epoch back to the round date of 1 January 1970, 00:00:00 UTC. Counting seconds instead of sixtieths stretched the same 32-bit counter to last until 2038 instead of 1973.

That's the entire reason. 1970 was recent, round, and convenient in the early 1970s — nothing more profound than that.

Why have a fixed "zero point" at all?

Storing time as one number counted from a fixed moment has three big advantages over storing "5 July 2026, 3:00 PM" as text:

Easy math. "Which event happened first?" becomes a simple number comparison. "How long between them?" is a subtraction. No wrestling with months of different lengths or leap years.
No time zones. The count is always in UTC. A server in Karachi and one in London write the same number for the same instant — the conversion to local time happens only when a human needs to read it.
Compact and fast. One integer is smaller and quicker to sort and index than a formatted date string.

This is why virtually every operating system, database and programming language stores time this way internally. (For a fuller explanation of what a timestamp is and how to read one, see what is a Unix timestamp.)

Why 1970 and not the year 0, or 1900?

A few practical reasons ruled out older starting points:

The year 0 doesn't really exist in the common calendar (it goes 1 BC → 1 AD), and counting billions of seconds across 2,000 years of messy calendar reforms would be a nightmare.
A recent date wastes fewer numbers. Computers in the 1970s had tiny amounts of memory. Starting near the present meant small, efficient numbers for current dates rather than huge ones.
1970 was "now-ish." A round year just before the work was done was the pragmatic engineer's choice — easy to reason about and document.

The date was later locked in by the POSIX standard, which is why it's identical across Linux, macOS, Android, iOS and almost everything else today.

What about dates before 1970?

They work fine — the count simply goes negative. A timestamp of -86400 is exactly one day before the epoch: 31 December 1969. So the "1970 wall" isn't a limit on what dates you can represent; it's just where the counting starts from. Historical dates are perfectly valid negative numbers.

This is also why a device with a dead clock or a software bug often shows "1 January 1970" — when the stored timestamp resets to 0, that's the date it lands on.

The flip side: the Year 2038 problem

If 1970 is the start, is there an end? For older systems, yes. A signed 32-bit integer maxes out at 2,147,483,647 seconds, which lands on 19 January 2038, 03:14:07 UTC. One second later, the counter overflows and wraps around to 1901 — the same family of bug as Y2K.

The fix is already standard: modern systems use 64-bit time values, which won't overflow for roughly 292 billion years. Try pasting 2147483647 into the Unix Timestamp Converter to see that exact 2038 moment for yourself.

Frequently asked questions

Can a Unix timestamp be negative?
Yes. Negative timestamps represent moments before the 1970 epoch — -1 is 31 December 1969, 23:59:59 UTC. The epoch is just the zero point of the number line, not the earliest representable date, so historical dates are stored as negative seconds.

Is the 1970 epoch the same in every time zone?
Yes. The Unix epoch is defined as 1 January 1970 at 00:00:00 UTC, and the count is always in UTC. That's the whole point — one universal number for an instant, converted to local time only for display. In Karachi that same instant reads as 5:00 AM on 1 January 1970, but the timestamp is identical.

Why not start counting from the year 0?
Because the year 0 doesn't exist in the standard calendar, older dates involve centuries of calendar reforms, and 1970s computers had little memory — a recent starting point kept the numbers small and the math simple. 1970 was chosen for convenience, not meaning.

Why do broken devices show 1 January 1970?
When a device loses its clock setting or a program reads an empty/zero timestamp, the value defaults to 0 — and 0 seconds after the epoch is exactly 1 January 1970, 00:00 UTC. That's why the "1970 glitch" appears on phones and gadgets with drained batteries.

Next time you see a stray "1970" on a screen, you'll know it's not a random glitch — it's the zero mark of the clock every computer counts from. Decode any real timestamp back to a human date with the Unix Timestamp Converter.

Originally published at cybercodelab.online.