November 13, 2026 is a Friday, so here's my favorite Friday the 13th story in computing. The Jerusalem virus was written to wipe out programs on that date. What got it caught was an ordinary bug in its own code, and the payload barely mattered.
What it did
Jerusalem was a DOS virus found at the Hebrew University of Jerusalem in late 1987. Run an infected program and the virus loaded itself into memory and stayed there. Every program you ran after that got infected too. About 30 minutes in, the machine slowed to a crawl.
The payload was a date check. If the system date was a Friday the 13th and the year wasn't 1987, the virus deleted every program you ran that day instead of infecting it. Because it skipped 1987, the first date it could fire was May 13, 1988.
The bug that gave it away
A virus is supposed to check whether a file is already infected before infecting it again. Jerusalem had that check. It just didn't work on .EXE files. Harold Highland's 1989 write-up says the author apparently forgot to set the signature when infecting them.
So every time an infected .EXE ran, it got another copy of the virus, 1,808 bytes more each time. .COM files grew once and stopped. The .EXE files kept growing until they no longer fit in memory. That's what people at the university noticed in December 1987. Programs had gotten too big to load.
I love this part. The payload ran on one or two days a year at most. The broken check ran every time someone opened a program. The infection code was supposed to stay hidden, and it's the part that exposed the virus before the payload ever fired.
Kaspersky's David Emm notes a second bug. The virus used DOS interrupt functions that NetWare also relied on, so on networked PCs it could knock workstations off the network or create huge spool files.
The parts people get wrong
Plenty of retellings say the first trigger was November 13, 1987. Kaspersky's own Securelist article says it. The code skips 1987, so that date did nothing.
May 13, 1988 also gets described as a global disaster. The university had warned users months ahead and handed out detection tools. Yisrael Radai, who did much of the analysis, said that to his knowledge no files were deleted that day. The first big public hit came later, in Britain on Friday, January 13, 1989.
Early press coverage floated a political motive tied to the anniversary of Israel's founding. Nobody ever identified the author, and that theory is speculation.
Whose Friday the 13th
Jerusalem read the PC's local clock. That's why the advice in 1988 was to set your system date forward or skip using the machine that day. A date check only means something once you decide whose calendar it runs on.
Web code has the same problem. A timestamp is an instant, not a day. Unix time hit 1234567890 at 23:31:30 UTC on Friday, February 13, 2009. In New York that was Friday evening. In Singapore, that same second was already Saturday morning.
function isFridayThe13th(date, timeZone) {
const parts = new Intl.DateTimeFormat("en-US", {
timeZone,
weekday: "short",
day: "numeric",
}).formatToParts(date);
const get = (type) => parts.find((p) => p.type === type).value;
return get("weekday") === "Fri" && get("day") === "13";
}
// Unix time is in seconds. Date wants milliseconds.
const moment = new Date(1234567890 * 1000);
console.log(isFridayThe13th(moment, "America/New_York")); // true
console.log(isFridayThe13th(moment, "Asia/Singapore")); // falseIf you write that check with getDay() and getDate() instead, you get the runtime's local zone. On a server that's usually UTC. In a browser it's whatever the user's machine says. So pass the zone in on purpose. If a scheduled job, a sale banner or a "no deploys today" rule keys off a date, write down which zone it means.
Friday the 13th carries no technical risk. A date check with an unstated time zone does.