Introduction

Converting a year into a century looks trivial until you hit boundary values such as 100, 1900, or 2000. The mistake most solutions make is forgetting that centuries start at year 1, not year 0, so exact multiples of one hundred belong to the century you just finished, not the next one.

The Correct Formula

For positive integer years, the standard formula is:

(year - 1) // 100 + 1

The subtraction by one is the key. It shifts the upper boundary of each century into the correct integer-division bucket.

1def century_from_year(year: int) -> int:
2    if year <= 0:
3        raise ValueError("year must be greater than zero")
4    return (year - 1) // 100 + 1
5
6
7print(century_from_year(1))
8print(century_from_year(100))
9print(century_from_year(101))
10print(century_from_year(2024))

Output:

11
21
32
421

This matches the historical convention: years 1 through 100 are the 1st century, years 101 through 200 are the 2nd century, and so on.

Why Plain Division Fails

A naive implementation often looks like this:

century = year // 100

That fails on most non-boundary years. For example:

• '1900 // 100 gives 19, which happens to be correct'
• '1901 // 100 also gives 19, which is wrong'

So the bug is not obvious if you only test round century values. That is why good test cases should include both the edge and the year immediately after it.

Another Equivalent Form

Some developers prefer a remainder-based approach:

1def century_from_year(year: int) -> int:
2    if year <= 0:
3        raise ValueError("year must be greater than zero")
4    return year // 100 if year % 100 == 0 else year // 100 + 1

This is logically fine, but the shifted formula is shorter and usually easier to reason about once you understand why it works.

JavaScript Version

The same idea translates directly to JavaScript:

1function centuryFromYear(year) {
2  if (year <= 0) {
3    throw new Error("year must be greater than zero");
4  }
5
6  return Math.floor((year - 1) / 100) + 1;
7}
8
9console.log(centuryFromYear(1705));
10console.log(centuryFromYear(1900));
11console.log(centuryFromYear(1901));

The important part is still the shift by one before division.

Testing the Right Cases

Boundary cases are where century logic proves itself. Good tests include:

• '1 should return 1'
• '100 should return 1'
• '101 should return 2'
• '2000 should return 20'
• '2001 should return 21'

If your function passes those, the rest of the range is usually correct as well.

Think About Domain Rules

Most programming exercises assume the input is a positive Gregorian-style year number. If you need to handle year zero, BCE dates, or historical calendar transitions, the question is no longer pure arithmetic; it becomes a domain modeling problem.

For example, astronomical year numbering uses a year zero, while many historical conventions do not. A generic helper function should document which interpretation it supports instead of pretending the distinction does not exist.

Common Pitfalls

The biggest pitfall is using year // 100 directly and believing it works because it passed one or two simple tests. It fails immediately after each century boundary.

Another common issue is not validating the input. If your function is only defined for positive years, reject zero and negative values explicitly.

Developers also sometimes mix the arithmetic with string formatting too early, returning labels such as 21st century from the same function. Keeping the numeric computation separate from display formatting makes testing easier and avoids coupling business logic to presentation rules.

Summary

• For positive years, the standard formula is (year - 1) // 100 + 1.
• Exact multiples of one hundred are the edge cases that expose incorrect solutions.
• Testing 100, 101, 2000, and 2001 is a quick way to validate the logic.
• Keep numeric century calculation separate from display formatting.
• If your application needs BCE or year-zero rules, define that behavior explicitly rather than assuming the simple formula covers it.