This is probably a combination of two things:

- computer people hate with a passion the Imperial calendar. Normal people are already annoyed when they have to do some calculation, in a decade+ spent here I never ever heard of anyone actively wanting to display or handle dates in the imperial/religious system. The only people I ever saw do it were required to.

- people who care the most about the imperial calendar use mostly paper and static data. It will be for printed forms, official announcements etc. The dynamic part will be mostly for this year or next year, and those will be up to date with the current/next area (also the sanest way to handle that is to have a unix date internally and only convert at display/parsing)

The announced plan was that Akihito would abdicate on April 30 and Naruhito would take the throne on May 1, so that Jan 1-Apr 30, 2019 would be Heisei 31 (平成31年) and May 1-Dec 31 would be Reiwa 1/Reiwa Gannen (令和元年).

The issue was with Windows Calculator's date calculation. If you ask it which day is 61 days after April 1, 2019, it correctly calculates June 1, 2019. The question, though, is what if you have your Windows settings set to show the Japanese era year - should it show "2019" in "June 1, 2019" as Heisei 31 or Reiwa 1?

If I remember right, the answer chosen was "it depends on what your computer's current clock time is!" In other words, if you ask Calculator while your PC's clock is set to April 2019 or earlier, it "wrongly" shows June 1, 2019 as in Heisei 31, but if your clock is set to May 2019 or later, June 1, 2019 is "correctly" shown as in Reiwa 1. This would be true even if the running Calculator and Windows code was already updated with the knowledge that the new era would be called "Reiwa." (Though the date when Reiwa would begin was specified by a law passed in 2017, Reiwa's name was only announced on April 1, 2019.)

(I forget whether this problem was solved in the calculator app itself or whether it inherited the solution from Windows' date and time formatting code.)

The justification was that the change of era would only be finalized when Akihito actually abdicated. In modern times, Akihito's abdication was the first time that the era changed without the reigning emperor dying. Calculator acting as if it knew before May 1, 2019 that Reiwa would begin on that day would thus be in bad taste, because it would be the moral equivalent of Calculator predicting or wishing for Akihito's death on April 30 - never mind that it was already well known that Akihito planned to abdicate on that day instead.

For example, a lot of camera date backs (used to physically embed time and date on film) could not be set to any date post a certain year, most commonly 2020 but I’ve also seen 2019 and 2029 as cutoffs. Even models that has a 4 digit year format isn’t immune from this issue, and sometimes it’s possible to bypass it by setting the date to Dec 31 2020, let the it roll over naturally to Jan 1 2021 and you will then be free to fast forward the date.

Maybe it’s similar to the YEAR 10000 bug on modern Windows OS where many internal variables could overflow beyond a certain datum so it would make sense to prevent it in the front end.

This isn't unusual. For example, the American calendar year 2024 belongs to both the school year "2023-2024" and the school year "2024-2025".

The general phenomenon here is "sometimes things begin when it isn't calendar New Year's Day", which is universal to all cultures.

Umm, wait, what? No, Gregorian centuries most definitely start at year xx01! The first century was from year 1 to 100, the second from 101 to 200, and so on. There was no year zero in the Gregorian calendar.

So if you are storing epoch time (no of milli seconds after 1970) in integer variables, your code will most probably break, which I feel is going to happen in a lot of scenarios.

Don't count on either changing soon.