An office argument, an NTP rabbit hole, and what payment gateways can teach us about trusting the clock

I was in the middle of a conversation with some colleagues when someone dropped a statement that immediately made me put down my coffee.

“JavaScript gives wrong time. We should never trust time from JavaScript — always rely on the server.”

Now I have a personal relationship with JavaScript. (I call it my girlfriend. Don’t judge.) So naturally, I pushed back.

My argument was simple: JavaScript isn’t lying to you. It’s reading from the system clock. If the system clock is wrong, that’s not JavaScript’s fault. That’s a machine configuration problem. JavaScript is just the messenger. You don’t blame WhatsApp for delivering a wrong message.

The counter-argument? “It’s still incorrect. In production, you can’t trust it. You haven’t worked on real projects. (also he said javascript is library and node js is a framework - i was like..dammm numb..)”

Wait. Hold on.

Let’s set aside the personal jab. The technical question is genuinely interesting — and the real answer is more nuanced than either side of that room was willing to admit.

So let me walk through everything I found when I actually went down this rabbit hole.

Round 1: What Does new Date() Actually Do?

When you write this in a browser:

const now = new Date();
console.log(now.toISOString());
// 2025-05-22T10:30:00.000Z

JavaScript is calling the system clock of the device running the code. That’s it. There’s no magic. No satellite connection. No atomic clock ping. It literally asks the OS: “Hey, what time is it?” and the OS says whatever it has been configured to say.

This means if a user manually changes their laptop clock to 2019, new Date() will happily tell you it's 2019.

So my colleagues weren’t wrong about the vulnerability. But I wasn’t wrong either — JavaScript isn’t broken. It’s doing exactly what it was designed to do. Garbage in, garbage out.

Round 2: The ChatGPT Plot Twist

Here’s where the conversation got interesting. Someone pulled out their phone and asked ChatGPT:

“Hey, does JavaScript give time according to system, and does Node.js give actual time?”

The answer?

“Not exactly — both JavaScript in the browser and Node.js use the system clock of the machine they are running on.”

The room went quiet.

Node.js — the “server-side” JavaScript runtime that everyone was claiming gives correct time — also reads from the system clock. At the OS level, there is no difference between new Date() in Chrome and new Date() in a Node.js Express server.

// Browser
console.log(new Date().toISOString()); // Uses OS clock

// Node.js server
console.log(new Date().toISOString()); // Also uses OS clock

Technically, they are the same call. So why does Node.js feel more trustworthy in production?

The answer has nothing to do with Node.js itself.

The Real Hero: NTP (Network Time Protocol)

Here’s the key insight that changes everything.

When your Node.js app runs on a production server — say, a VPS you bought from Hostinger, DigitalOcean, or AWS — that server’s OS clock is automatically synchronized with the internet via something called NTP: Network Time Protocol.

You didn’t write a single line of code for this. The cloud provider handled it. Their Linux boxes run an NTP client (like chrony or ntpd) that continuously talks to a hierarchy of highly accurate time servers — ultimately tracing back to atomic clocks maintained by national standards bodies like NIST in the US or NPL in the UK.

# On a Linux server, you can check NTP sync status:
timedatectl status

# Output looks like:
#      System clock synchronized: yes
# NTP service: active

This is the real reason server time is more reliable. Not because Node.js is special. Because servers are usually NTP-synced and user devices often aren’t.

A user’s laptop might have “Set time automatically” turned off. Their phone might have been in airplane mode for three days. Your EC2 instance, on the other hand, is in a data center that keeps its clocks accurate to within milliseconds of UTC.

So the correct framing is:

Source Uses System Clock?

Usually NTP-synced?

Trustworthy for production?

Browser new Date() ✅ Yes ❓ Maybe ❌ No Node.js new Date() ✅ Yes ✅ Usually ✅ Yes (because of the environment, not the language)

So What Do We Actually Do in Code?

Let’s get practical. Here are the patterns you should know.

1. Never Use Client Time for Critical Logic

This is the rule. If you’re calculating order expiry, session timeout, or anything that matters — do it on the server.

// ❌ Bad: Trusting the client for time-sensitive logic
const orderExpiry = new Date(Date.now() + 30 * 60 * 1000); // 30 minutes from "now"
fetch('/api/place-order', {
  body: JSON.stringify({ expiry: orderExpiry }) // Client-generated timestamp
});

// ✅ Good: Let the server decide
fetch('/api/place-order', {
  body: JSON.stringify({ items: cart }) // No timestamp — server will stamp it
});

// On the server (Node.js / Express):
app.post('/api/place-order', (req, res) => {
  const order = {
    ...req.body,
    createdAt: new Date().toISOString(), // Server-generated, NTP-synced
    expiresAt: new Date(Date.now() + 30 * 60 * 1000).toISOString(),
  };
  // Save to DB...
});

2. Always Store Time as UTC

This is non-negotiable. Never store "10:30 PM". Always store "2025-05-22T17:00:00.000Z". The Z at the end means UTC — a single reference point the entire world agrees on.

// ❌ Storing local time — a disaster waiting to happen
const timestamp = new Date().toLocaleString(); // "5/22/2025, 10:30:00 PM"
// Which timezone? IST? PST? Who knows.

// ✅ Storing UTC — always unambiguous
const timestamp = new Date().toISOString(); // "2025-05-22T17:00:00.000Z"

3. Display Time Relative to the User’s Locale — Let the Browser Handle It

Here’s the beautiful part. Once your backend stores everything in UTC, the browser can automatically convert it to the user’s local timezone. You don’t have to write timezone conversion logic.

// You get this UTC string from your API:
const utcTimestamp = "2025-05-22T17:00:00.000Z";

// Display it in the user's local timezone automatically:
const localDate = new Date(utcTimestamp);
console.log(localDate.toLocaleString()); 
// In India: "22/5/2025, 10:30:00 pm"
// In New York: "5/22/2025, 1:00:00 PM"
// In London: "22/05/2025, 18:00:00"

The browser reads the device timezone and converts accordingly. Physics is doing the work — time is relative to the observer’s location, and JavaScript’s toLocaleString() handles that relativity correctly.

4. Use a Proper Date Library for Complex Operations

For anything beyond basic display — date arithmetic, duration formatting, timezone-aware comparisons — use a battle-tested library.

// Using date-fns (lightweight, tree-shakeable)
import { formatDistanceToNow, isAfter, parseISO } from 'date-fns';

const orderTime = parseISO("2025-05-22T10:00:00.000Z");

console.log(formatDistanceToNow(orderTime)); 
// "about 2 hours ago"

const deadline = parseISO("2025-05-22T12:00:00.000Z");
if (isAfter(new Date(), deadline)) {
  console.log("Order window has closed.");
}

The Payment Gateway Story: Where Time Gets Wild

This is the part I find genuinely fascinating.

When you make a payment — say, an EMI that’s due on May 31st at 11:59 PM — which 11:59 PM counts? The payment gateway is in a data center in Mumbai. The bank’s server might be in Pune. You’re making the payment from your phone in Jaipur. Your payment app is showing time from its own servers.

How do these systems avoid chaos?

The Answer: Epoch Timestamps + UTC Reference

Every serious payment system stores and compares times as Unix epoch milliseconds — the number of milliseconds since January 1, 1970, 00:00:00 UTC. It’s a single integer. No timezone ambiguity. No DST confusion.

// Instead of comparing "May 31st 11:59 PM IST"
// They compare epoch values:

const dueDate = 1748703540000; // A specific UTC moment in epoch ms
const paymentTime = Date.now(); // Server-generated epoch ms (NTP-synced)

if (paymentTime <= dueDate) {
  // Payment is on time ✅
} else {
  // Payment is late ❌
}

The Grace Period Problem

Here’s a real story-worthy edge case. Imagine two things happen simultaneously:

• At T = 0ms: The payment gateway server logs your payment as received
• At T = +200ms: The bank's server processes the transaction and stamps it

Those 200 milliseconds could push a payment from “before midnight” to “after midnight” depending on which timestamp is considered authoritative. This is why payment systems define a canonical timestamp source — usually one authoritative service that all parties agree to use — and build in grace periods (often 5–15 minutes) for exactly these clock-skew scenarios.

RBI guidelines, for example, require payment systems to maintain time synchronization within acceptable bounds precisely because of this.

This is also why in your EMI apps you’ll sometimes see “Last date: May 31 — payments accepted until 11:59 PM IST” but the actual cutoff in the system might be 12:05 AM June 1 UTC — the grace window accounting for clock skew across systems.

Summary: The Cheat Sheet

Let me save you the office argument next time:

1. JavaScript's new Date() → reads system clock (always)
2. Node.js new Date()     → also reads system clock (always)
3. Server time > Client time → because servers are NTP-synced, not because of the language
4. Store everything in UTC (ISO 8601 format)
5. Display using toLocaleString() — let the browser handle timezone conversion
6. Critical comparisons → use epoch milliseconds on the server side
7. Payment systems → define one canonical time source + build in grace periods

Final Thought

The person who said “JavaScript gives wrong time” was pointing at a real problem — but misattributing the cause. JavaScript is faithfully reporting what the machine tells it. The machine is the unreliable one.

And the person who said “Node.js gives actual time” was right in practice — but wrong in theory. It’s the server environment, not Node.js itself, that makes the difference.

The real lesson? Time is a distributed systems problem. The moment you have two machines that need to agree on “when” something happened, you’ve entered a world of NTP hierarchies, epoch timestamps, clock skew, and grace periods.

And JavaScript, my faithful girlfriend, is just caught in the middle.

If you found this useful, drop a clap (or 50 — they’re free 😄). I’ll be writing more about the hidden complexity inside everyday web development. Next up: how do session tokens handle expiry when the server clock drifts?

Tags: JavaScript Node.js Web Development Backend Software Engineering