JavaScripts Date-parser är kaos: Route 66 blir ett datum

Skriv new Date("Route 66") i din browsers konsol. Gå vidare, testa. Du får tillbaka 1 januari 1966. JavaScript såg siffran 66, antog att det var ett årtal, och skapade glädjenämligen ett Date-objekt. Ingen varning, inget fel — bara en helt felaktig tolkning.

Det här är inte en edge case. Det är Date.parse() som fungerar exakt som det är designat. Och en tråd på r/programming med över 350 upvotes visade nyligen att utvecklare över hela världen har fått nog.

Date-parsern är inte trasig — den är för snäll

JavaScripts Date-konstruktor försöker desperat tolka allt du ger den som ett datum. Problemet är att ”allt” verkligen betyder allt. V8 och SpiderMonkey (motorerna bakom Chrome och Firefox) använder heuristiker som letar efter siffror i strängen och gör sitt bästa för att skapa något meningsfullt.

// JavaScript Date: en parser utan gränser

new Date("Route 66")
// → Sat Jan 01 1966 00:00:00
// Ser "66", antar att det är ett årtal

new Date("Beverly Hills, 90210")
// → Mon Jan 01 90210 00:00:00
// Ser "90210", skapar ett datum 88 000 år i framtiden

new Date("Catch 22")
// → Invalid Date
// "22" ligger i 13-31-spannet — parsern ger upp

new Date("Friday 13")
// → Invalid Date
// Men...

new Date("Friday 13 October")
// → Fri Oct 13 2006 00:00:00
// Nu hittar den månad + dag och gissar ett årtal

Mönstret är tydligt: parsern letar efter siffror, gör antaganden om vad de representerar, och skapar ett datum. När antagandena är fel får du inget felmeddelande — du får ett datum som ser legitimt ut men är helt galet.

Samma sträng, olika resultat

Det mest frustrerande med Date är att beteendet varierar mellan browsers. ISO 8601-standard (YYYY-MM-DD) borde vara säker, men även där lurar fällor.

// Timezone-fällan med ISO-format
new Date("2026-04-10")
// Chrome: Thu Apr 09 2026 19:00:00 GMT-0500 (CDT)
// Tolkas som UTC → visas som lokal tid → FEL DAG i västra halvklotet

new Date("2026-04-10T00:00:00")
// Chrome: Thu Apr 10 2026 00:00:00 (lokal tid)
// Med "T" tolkas det som lokal tid — rätt dag

// Locale-formatet är ännu värre
new Date("10/03/2026")
// USA (Chrome): October 3
// Europa-förväntning: 10 mars
// Parsern: MM/DD/YYYY alltid, oavsett locale

Det här är exakt den typen av bugg som gländer igenom code reviews. Koden ser korrekt ut, testerna passerar (på utvecklarens maskin), och sedan kraschar det i produktion för användare i en annan tidszon.

Off-by-one-dag: en bugg som kostar pengar

Den vanligaste Date-buggen i produktion är inte bisarr — den är subtil. När du skriver new Date("2026-04-10") utan tidskomponent tolkar JavaScript det som UTC midnatt. För alla i UTC-negativa tidszoner (hela Nord- och Sydamerika) blir det föregående dag.

// Användare i Stockholm (UTC+2): Rätt
new Date("2026-04-10").toLocaleDateString("sv-SE")
// → "2026-04-10" ✓

// Användare i New York (UTC-5): Fel
new Date("2026-04-10").toLocaleDateString("en-US")
// → "4/9/2026" ← FEL DAG

// Fixa med explicit tid
new Date("2026-04-10T00:00:00").toLocaleDateString("en-US")
// → "4/10/2026" ✓

// Eller ännu bättre — specificera tidszonen
new Date("2026-04-10T00:00:00+02:00").toLocaleDateString("en-US")
// → "4/9/2026" eller "4/10/2026" beroende på lokal tz

I e-handel betyder det att en beställning lagd den 10 april kan registreras som den 9 april. I bokningssystem kan det innebära att du bokar fel dag. I rapporter kan det skifta hela dagars data till fel datum.

Vad communityn säger

Reddit-tråden avslöjade några mönster i hur utvecklare hanterarDate-problemen i praktiken:

• ”Lagra alltid som UTC, konvertera vid visning” — den vanligaste rekommendationen. Låter enkelt, men kräver disciplin i hela stacken.
• ”Undvik Date-konstruktorn med strängar” — användnew Date(2026, 3, 10) (observera: månader är 0-indexerade) ellerDate.UTC() istället.
• ”Vi har slutat använda Date helt” — team som migrerat till date-fns, Luxon eller dayjs och aldrig tittat tillbaka.
• ”Vänta på Temporal” — den växande konsensus att Temporal API är den riktiga lösningen.

Temporal API: Date-parserns pensionering

TC39:s Temporal-förslag (Stage 3) är det mest genomgripande tillskottet till JavaScript sedan async/await. Det har landat i Chrome 144 och Firefox — och Safari följer efter. Skillnaden mot Date är fundamental.

// Date: muterbar, tvetydig, farlig
const date = new Date();
date.setDate(date.getDate() + 1); // Muterar originalet!
console.log(date); // Vad var originaldatumet? Borta.

// Temporal: immutabel, tydlig, säker
const today = Temporal.Now.plainDateISO();
const tomorrow = today.add({ days: 1 });
console.log(today);    // Oförändrad
console.log(tomorrow); // Ny instans

// Temporal: explicit tidszon
const stockholm = Temporal.Now.zonedDateTimeISO("Europe/Stockholm");
const newYork = stockholm.withTimeZone("America/New_York");

// Temporal: duration utan gissningar
const duration = Temporal.Duration.from({ hours: 2, minutes: 30 });
const meeting = stockholm.add(duration);

// Temporal: parsing som faktiskt felar vid ogiltig input
Temporal.PlainDate.from("Route 66");
// → RangeError: invalid ISO 8601 string
// ÄNTLIGEN! Ett riktigt felmeddelande.

De tre största förbättringarna i Temporal:

1. Immutabilitet — metoder returnerar nya objekt istället för att mutera. Inga fler ”var det här datumet före eller efter jag anropade setDate?”-buggar.
2. Explicit tidszon — ZonedDateTime vet vilken tidszon den tillhör. Ingen implicit konvertering, inga överraskningar.
3. Strikt parsing — ogiltiga strängar ger fel istället för galna datum. "Route 66" blir ett RangeError, inte 1 januari 1966.

Vad du bör göra idag

Temporal är inte redo för alla ännu — Safari-stöd saknas och polyfills lägger till bundle-storlek. Men du kan förbereda din kodbas:

// 1. Sluta använda Date-konstruktorn med strängar
// ❌ Farligt
new Date("2026-04-10")

// ✅ Explicit
new Date(2026, 3, 10) // Observera: månad 3 = april (0-indexerat)

// 2. Validera ALLTID datumsträngar innan parsing
function parseDate(str: string): Date {
  const parsed = new Date(str);
  if (isNaN(parsed.getTime())) {
    throw new Error(`Invalid date string: ${str}`);
  }
  return parsed;
}

// 3. Använd Intl.DateTimeFormat för visning
const formatter = new Intl.DateTimeFormat("sv-SE", {
  year: "numeric",
  month: "long",
  day: "numeric",
});
formatter.format(new Date(2026, 3, 10));
// → "10 april 2026"

// 4. Om du behöver tidszon-hantering: date-fns-tz eller Luxon
import { formatInTimeZone } from "date-fns-tz";
formatInTimeZone(
  new Date(),
  "Europe/Stockholm",
  "yyyy-MM-dd HH:mm:ss"
);

Därför dör inte Date (men du behöver inte lida)

Date kommer aldrig att försvinna från JavaScript — det skulle bryta miljontals webbsidor. Men med Temporal på väg in i språket finns det äntligen ett alternativ som är designat för hur vi faktiskt arbetar med datum och tid.

Tills dess: validera dina strängar, var explicit med tidszoner, och låt aldrigDate göra antaganden åt dig. För om du ger den ”Beverly Hills, 90210” kommer den glädjenämligen skapa ett datum 88 000 år in i framtiden — utan att rodna.