Using the Japanese Era Calendar in AI-Generated Dates

Japanese government forms, contracts, driving licences and residence cards number the year from the start of the current imperial era, not from year zero. A model asked for a Japanese-format date will often produce the Gregorian year with Japanese characters around it, which is legible but is not what the form asks for.

What a gengo year is

The era name system — 元号, gengo — counts years from the accession of an emperor. The current era is Reiwa (令和), which began on 1 May 2019 when Emperor Naruhito acceded. Today’s date in that system is written 令和8年8月11日: Reiwa year 8, month 8, day 11.

It is not a parallel calendar in the sense that the Hijri or Hebrew calendars are. Months and days are exactly the Gregorian ones — Japan adopted the Gregorian calendar in 1873 — so only the year number changes. That is why the conversion is a subtraction rather than a calendar computation, and also why the mistake is easy to miss: a date with the right month and day and the wrong year number still looks like a date.

Usage is not uniform. Government paperwork, court documents, newspapers in their datelines and most official forms use gengo. Software, international business and much of everyday digital life use the Gregorian year, called 西暦 (seireki). Many forms print both and expect you to circle one. The practical rule for generated content is that anything modelled on a Japanese official document needs gengo, and anything else probably does not.

The arithmetic, both directions

Each era has a constant offset, which is the Gregorian year before the era began:

Reiwa   令和   1 May 2019 -> present     Gregorian = Reiwa  + 2018
Heisei  平成   8 Jan 1989 - 30 Apr 2019   Gregorian = Heisei + 1988
Showa   昭和   25 Dec 1926 - 7 Jan 1989   Gregorian = Showa  + 1925
Taisho  大正   30 Jul 1912 - 25 Dec 1926   Gregorian = Taisho + 1911
Meiji   明治   1868 - 30 Jul 1912          Gregorian = Meiji  + 1867

So Reiwa 8 is 2018 + 8 = 2026, and 2026 is Reiwa 2026 − 2018 = 8. Heisei 31 is 1988 + 31 = 2019, which is correct: Heisei ran until 30 April of that year. Showa 64 is 1925 + 64 = 1989, and lasted seven days.

The boundary dates are the part to get right, because the offset is a function of the date, not the year. A document dated 3 March 2019 is Heisei 31, and one dated 3 June 2019 is Reiwa 1, and both are 2019. Any conversion routine that takes only a year is wrong for transition years by construction, which is five distinct years since 1868 and one of them is recent enough to appear in live data.

Year one is not written 1

The first year of an era is written 元年 (gannen, “origin year”), not 1年. So 2019 in its Reiwa half is 令和元年, and 1989 in its Heisei half is 平成元年. Writing 令和1年 is not exactly an error — it is understood, and it appears in database dumps — but it reads as machine output, and on a printed form it looks wrong.

Abbreviated forms use the era’s initial Latin letter: R for Reiwa, H for Heisei, S for Showa, T for Taisho, M for Meiji. Today appears as R8.8.11 or R8/08/11 on compact forms. This is where the pre-2019 era letters still matter: a birth date on a Japanese document belonging to someone born in 1975 is written S50, and any parser handling identity documents needs all five letters, not just the current one.

The transition year is ambiguous

Given only “year 31” and “year 1” with no era name, a converter cannot recover 2019 reliably, and given only 2019 it cannot decide which era name to print. That is not a defect in any particular implementation; the information is genuinely not present.

The consequences show up in a specific place: fiscal and academic years, which in Japan run from April. The Japanese fiscal year beginning in April 2019 is 令和元年度 — Reiwa 1 — even though its first month fell under Heisei by a few weeks in some framings and the year is named for its starting April. Anything that computes a Japanese fiscal-year label by subtracting a constant from a Gregorian year will be wrong for that one year in a way that only a Japanese accountant will notice. The general problem of what a fiscal-year label means in each country is worth reading alongside this.

Where software gets the data

You should not implement the table above. Every major platform ships it, because it has to be patched when an era changes:

// JavaScript, via ECMA-402
new Intl.DateTimeFormat("ja-JP-u-ca-japanese", { era: "long", dateStyle: "long" })
  .format(new Date("2026-08-11"));

// Java
java.time.chrono.JapaneseDate.from(LocalDate.of(2026, 8, 11));
java.time.chrono.JapaneseEra.REIWA;

// ICU / CLDR
// calendar type "japanese"; era names live in the ja locale data

The locale extension -u-ca-japanese is the part people miss: the language tag ja-JP alone gives Japanese-language output on the Gregorian calendar. The calendar is a separate axis from the language, which is the right design — a Japanese-language interface for an international audience usually wants Gregorian years, and the same system needs both.

What happens when the era changes

An era ends when a reign ends, and the new name is announced with very little notice. The Reiwa transition was unusual in being planned: the abdication was legislated in advance and the name was announced on 1 April 2019 for an era beginning 1 May. Even with a month’s warning, that month was a scramble across the industry — operating systems, runtimes, ICU builds, printers and every application with a hard-coded table had to ship an update, and Unicode added the single-character square era name U+32FF for Reiwa in Unicode 12.1, a release published in May 2019 for essentially this one character.

The design consequence is straightforward. Do not store gengo. Store an unambiguous absolute date and convert at display time, so that when the era changes you update a library and your stored data is untouched. A system that stored 令和 plus a year number as its date of record would need a migration, and the migration would have to reason about the exact accession date to be correct for the transition year.