
`Date` represents a single moment in time as the number of milliseconds since January 1, 1970 UTC (the Unix epoch). The object itself carries no timezone. The browser or runtime locale is only applied when you format the date as human-readable text.

<ExamplePair>
<ExampleProse>

You create a `Date` with `new Date()` for the current moment, `new Date(milliseconds)` for a specific instant, or `new Date("YYYY-MM-DD")` for an ISO date string. ISO 8601 strings are safe to parse across environments. Locale-formatted strings like `"April 27, 2026"` are not. `.getTime()` returns the raw epoch millisecond value.

</ExampleProse>
<ExampleCode>

```js
const now = new Date();
console.log(now);              // e.g. 2026-04-27T12:34:56.789Z

const fromMs = new Date(0);
console.log(fromMs);           // 1970-01-01T00:00:00.000Z

const fromISO = new Date("2026-04-27");
console.log(fromISO.getTime()); // epoch milliseconds for that date

// Avoid locale-formatted strings - parsing varies by runtime
const risky = new Date("April 27, 2026"); // not reliable everywhere
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`<` and `>` work between two `Date` objects because JavaScript coerces them to numbers (epoch ms) for the comparison. `===` does not work for equality because it compares object identity. Two separate `Date` objects representing the same moment are never `===` each other.

</ExampleProse>
<ExampleCode>

```js
const a = new Date("2026-04-27");
const b = new Date("2026-04-27");

console.log(a === b); // false - different objects in memory
console.log(a < b);   // false
console.log(a > b);   // false

// Compare for equality using epoch milliseconds
console.log(a.getTime() === b.getTime()); // true

const later = new Date("2026-12-31");
console.log(a < later); // true
console.log(a > later); // false
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`Intl.DateTimeFormat` formats a date for a specific locale and timezone - use it for what users read. `.toISOString()` produces a UTC string that is safe for storage, logs, and APIs. The two serve different purposes: one for humans, one for machines.

</ExampleProse>
<ExampleCode>

```js
const date = new Date("2026-04-27T15:30:00Z");

// For users: locale-aware output
const formatter = new Intl.DateTimeFormat("en-US", {
  year: "numeric",
  month: "long",
  day: "numeric",
  timeZone: "America/New_York",
});
console.log(formatter.format(date)); // "April 27, 2026"

// Short form
console.log(date.toLocaleDateString("en-US")); // "4/27/2026"

// For storage and APIs: UTC, always consistent
console.log(date.toISOString()); // "2026-04-27T15:30:00.000Z"
```

</ExampleCode>
</ExamplePair>

<InProduction>
Store epoch milliseconds or ISO strings in databases and APIs, never wall-clock strings like `"April 27, 2026"` - those are ambiguous outside the locale that produced them. `Date` is mutable, and `===` between two instances is always `false`, so treat dates as values you compare with `.getTime()`. For anything beyond rendering today's date (date arithmetic, relative formatting, timezone logic) reach for date-fns or Luxon, or wait for the `Temporal` API once your runtime ships it.
</InProduction>


Creating, comparing, and formatting dates with the built-in Date object, and why you should store epoch milliseconds or ISO strings and format at the edge.

Dates


`class` is syntactic sugar over JavaScript's prototype system. Each instance gets methods shared on the prototype, and `this` inside a method refers to whatever object the method was called on - not where the method was defined. That distinction is the source of most class-related bugs.

<ExamplePair>
<ExampleProse>

A class groups related state and behavior. The `constructor` runs when you call `new` and sets up instance properties. Methods are defined in the class body and are available on every instance through the shared prototype.

</ExampleProse>
<ExampleCode>

```js
class Counter {
  constructor(start = 0) {
    this.count = start;
  }

  increment() {
    this.count += 1;
  }

  decrement() {
    this.count -= 1;
  }

  value() {
    return this.count;
  }
}

const c = new Counter();
c.increment();
c.increment();
c.increment();
c.decrement();
console.log(c.value()); // 2

const c2 = new Counter(10);
c2.increment();
console.log(c2.value()); // 11
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`this` is bound at the call site. Pulling a method off an instance and calling it as a plain function loses the binding. Classes always run in strict mode, so `this` becomes `undefined` (not `window`) and the call throws.

</ExampleProse>
<ExampleCode>

```js
class Counter {
  constructor() {
    this.count = 0;
  }

  increment() {
    this.count += 1; // 'this' depends on how this function is called
  }
}

const c = new Counter();
c.increment();        // works - this === c
console.log(c.count); // 1

// Detach the method from its object
const inc = c.increment;
inc(); // TypeError: Cannot set properties of undefined

// The same problem arises when passing a method as a callback
setTimeout(c.increment, 100); // this is undefined inside increment
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

Three patterns fix the lost binding. Each has a different trade-off: binding in the constructor is compatible everywhere; class-field arrows are the modern default; wrapping at the call site is a one-off fix when you don't control the class.

</ExampleProse>
<ExampleCode>

```js
// Fix 1: bind in the constructor (works in all environments)
class Counter1 {
  constructor() {
    this.count = 0;
    this.increment = this.increment.bind(this);
  }
  increment() { this.count += 1; }
}

// Fix 2: class field arrow (modern - arrow captures this at construction)
class Counter2 {
  count = 0;
  increment = () => { this.count += 1; };
}

// Fix 3: wrap at the call site (one-off, doesn't fix the class itself)
class Counter3 {
  constructor() { this.count = 0; }
  increment() { this.count += 1; }
}

const c1 = new Counter1();
const inc1 = c1.increment;
inc1(); // works
console.log(c1.count); // 1

const c2 = new Counter2();
const inc2 = c2.increment;
inc2(); // works
console.log(c2.count); // 1

const c3 = new Counter3();
setTimeout(() => c3.increment(), 100); // works - arrow at call site
```

</ExampleCode>
</ExamplePair>

<InProduction>
`this` is bound at the call site, not the definition site. The moment a method is passed as a callback the binding is gone. The class-field arrow (`increment = () => { ... }`) is the modern fix and requires no extra thought at every call site. Use `.bind(this)` in the constructor for environments or codebases that avoid class fields. Wrapping in an arrow at the call site patches the symptom without fixing the class.
</InProduction>


The class syntax, prototype-based inheritance under the hood, and the this-rebinding bug that breaks methods the moment they are passed as callbacks.

Classes and `this`


`Map` is a keyed collection where keys can be any value, not just strings. `Set` is a collection of unique values where duplicates are ignored automatically. Plain objects coerce all keys to strings; arrays don't deduplicate. Both are built into modern JavaScript.

<ExamplePair>
<ExampleProse>

`Map` works like a dictionary. You add entries with `.set(key, value)`, retrieve them with `.get(key)`, and check for a key with `.has(key)`. Iteration follows insertion order, which plain objects don't guarantee on all runtimes.

</ExampleProse>
<ExampleCode>

```js
const scores = new Map();

scores.set("alice", 95);
scores.set("bob", 87);
scores.set("carol", 92);

console.log(scores.get("alice")); // 95
console.log(scores.has("bob"));   // true
console.log(scores.has("dave"));  // false
console.log(scores.size);         // 3

// Iteration order matches insertion order
for (const [name, score] of scores) {
  console.log(`${name}: ${score}`);
}
// alice: 95
// bob: 87
// carol: 92
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`Map` accepts any value as a key, including objects, functions, and even `NaN`. A plain object coerces every key to a string, so using an object as a key silently collapses all such keys to `"[object Object]"`.

</ExampleProse>
<ExampleCode>

```js
const userCache = new Map();

const user1 = { id: 1, name: "Alice" };
const user2 = { id: 2, name: "Bob" };

userCache.set(user1, { lastSeen: "2026-04-27" });
userCache.set(user2, { lastSeen: "2026-04-26" });

console.log(userCache.get(user1)); // { lastSeen: "2026-04-27" }
console.log(userCache.get(user2)); // { lastSeen: "2026-04-26" }

// The same attempt on a plain object
const plainObj = {};
plainObj[user1] = "alice data";
plainObj[user2] = "bob data";

// Both keys stringify to "[object Object]" and clobber each other
console.log(Object.keys(plainObj)); // ["[object Object]"]
console.log(plainObj[user1]);       // "bob data" - wrong
```

</ExampleCode>
</ExamplePair>

<ExamplePair>
<ExampleProse>

`Set` stores unique values in insertion order. Adding a duplicate is silently ignored. Spreading a `Set` back into an array (`[...new Set(arr)]`) is the shortest idiom for deduplicating.

</ExampleProse>
<ExampleCode>

```js
const tags = new Set();

tags.add("javascript");
tags.add("web");
tags.add("javascript"); // duplicate - ignored
tags.add("node");

console.log(tags.size);              // 3
console.log(tags.has("javascript")); // true
console.log(tags.has("python"));     // false

tags.delete("web");
console.log([...tags]); // ["javascript", "node"]

// One-liner dedup of an array
const nums = [1, 2, 3, 2, 1, 4];
const unique = [...new Set(nums)];
console.log(unique); // [1, 2, 3, 4]
```

</ExampleCode>
</ExamplePair>

<InProduction>
Reach for `Map` whenever keys aren't string literals or insertion order matters, and reach for `Set` whenever you'd otherwise write `arr.includes(x)` inside a loop (a linear scan each call). A `Set.has()` check is O(1). Plain objects also walk the prototype chain, so keys like `toString` or `constructor` collide with inherited properties - `Map` has no such issue.
</InProduction>


Keyed collections that accept any value as a key (Map) and deduplicated collections (Set) - when to reach for them instead of plain objects and arrays.