The Y1C Problem: Taiwan's ROC Year 100 Date Bug

On 1 January 2011 Taiwan's ROC (Minguo) calendar reached year 100 — the first three-digit year since the calendar began in 1912. Software that stored the year in two digits could not represent it. This is the story of Taiwan's own Y2K, and what it still means for anyone writing software that handles Taiwanese dates.

The setup

The ROC calendar counts years from the founding of the Republic of China in 1912, which is ROC year 1. It is otherwise the Gregorian calendar: months and days are identical, and only the year count differs. So Gregorian year = ROC year + 1911.

For the calendar's first 99 years, every ROC year fitted in two digits. Databases, form fields, printed stationery, fixed-width file formats and report templates were all built on that assumption — the same assumption, and the same mistake, that produced the Year 2000 problem elsewhere.

Then 2011 arrived, and the ROC year became 100.

What a two-digit field does at the rollover

The failure mode is the giveaway: a two-digit field holding ROC 100 shows 00, which reads as ROC year 0 — a year that does not exist. There is no ROC year zero, because 1911 and earlier count backwards as "before ROC" (民國前). A system displaying year 00 is not showing an early date; it is showing a truncation.

Why the damage was small

Taiwan had a significant advantage: it had already been through Y2K remediation a decade earlier, and the Y1C rollover was flagged years in advance — Pinyin News was writing about it in 2006, and international coverage followed in mid-2010.

There was also a quieter structural reason. Many systems already stored the ROC year in three digits with a leading zero, so ROC 99 was held as 099 and the transition to 100 needed no change at all. And some documents had been carrying years above 100 for a long time already: a driver's licence issued in ROC 95 with a long validity period necessarily printed an expiry date past ROC 100, so those systems had been forced to handle three digits years before the rollover.

The outcome, per the record of the event, was minor glitches rather than failures.

A documented example

One concrete case survives in vendor documentation. In Crystal Reports XI R2, a date field using the ROC calendar displayed only the last two digits of the year, so ROC 100 rendered as 00. SAP documented the defect and fixed it in Service Pack 4. It is a useful illustration because it shows the bug living in a reporting layer rather than in storage — the underlying data was fine; the rendering was not.

What this still means for software today

The three-digit transition is fifteen years behind us, but ROC dates continue to break systems that were not designed for them. Four rules cover most of it.

1. Store the ROC year in at least three digits

Zero-pad to three when the format is fixed-width: 099, 100, 115. Two digits is the original bug; four digits invites confusion with Gregorian years.

2. Never infer the calendar from the number alone

A date written 100/1/1 is ambiguous without context — it could be ROC 100 (1 January 2011) or a malformed Gregorian date. In practice a three-digit year in the low hundreds is a ROC year, because no Gregorian year is written that way, but the safe approach is to carry the calendar as explicit metadata rather than guessing from the value.

3. Remember there is no year zero

ROC 1 is 1912. Dates before that are "before ROC N", where N = 1912 − Gregorian year, so 1911 is before ROC 1 and 1900 is before ROC 12. A naive gregorian − 1911 produces 0 and then negative numbers, which is not how the calendar is written. Handle the pre-1912 range as a separate signed case.

4. Convert the year only

Months and days are identical between the ROC and Gregorian calendars. Any conversion routine that touches the month or day is doing something wrong. This also means ROC dates sort correctly as integers once the year is normalised, with no calendar-specific comparison logic needed.

Try the conversion

The ROC year converter handles the full range including the pre-1912 "before ROC" years, and shows the formal written form used on Taiwanese paperwork. The 1883–2031 reference table lists every year alongside its ganzhi, zodiac animal and Qing or Japanese era name.

This page is a technical and historical reference. It is not affiliated with any government agency or software vendor.

Frequently asked questions

What was the Y1C problem?

Taiwan's ROC (Minguo) calendar counts 1912 as year 1, so the Gregorian year 2011 was ROC year 100 — the first three-digit year in the calendar's history. Software that stored or displayed the ROC year in only two digits could not represent it, and would show 00 or wrap around. The problem is named by analogy with Y2K and is also called the Minguo Year 100 bug (民國百年蟲).

When did the Y1C problem occur?

At the transition from 31 December 2010 to 1 January 2011, when ROC year 99 became ROC year 100.

How much damage did it actually cause?

Very little. Taiwan had been through Y2K remediation a decade earlier, and many systems already stored the ROC year in three digits with a leading zero, so 099 simply became 100. Only minor glitches were reported.

Is the ROC calendar still a problem for software today?

The three-digit transition is long past, but ROC years still catch out systems that assume a two-digit or four-digit year. The main risks now are parsing ambiguity — 100/1/1 could be read as a Gregorian date — and the fact that there is no ROC year zero, since years before 1912 count backwards as "before ROC".

What is the conversion between ROC and Gregorian years?

Gregorian year = ROC year + 1911, and ROC year = Gregorian year − 1911. Months and days are identical in both calendars, so only the year needs converting. ROC 100 is 2011 and ROC 115 is 2026.

Will there be a similar problem at ROC year 1000?

ROC 1000 is the Gregorian year 2911, so it is not a practical concern. Any system storing the ROC year in three digits is safe for roughly the next nine centuries.