As ownership of the Notes and Domino platform passes from IBM to HCL in the coming weeks, we’ve heard this transition being hailed as the dawning of a new era. While it does a nice job of describing the excitement that many of us feel about the event, of course in reality it is just a turn of phrase. But in Japan last month, we literally experienced the dawn of a new era. And it’s caused some issues for Notes and Domino developers that the rest of us can learn from. Allow me to explain.
We’ve had an office in Tokyo since 2001, and in my travels there I’ve gradually become accustomed to the many cultural and practical differences between Japan and the United States. But I recently learned about a difference that had eluded me until now, and yet has a potentially significant impact on our customers’ IBM Notes and Domino applications.
It’s to do with date formats. Mostly, especially in business, Japanese people use the Gregorian calendar, as does most of the rest of the world. The way the Japanese write dates in numerical form is typically as yyyy-mm-dd, which seems to me much more logical than either the British (dd-mm-yyyy) or the American (mm-dd-yyyy) formats. (If it wasn’t obvious, in the Japanese form, the most significant digits are always to the left, making it easier to sort a list of dates as text.)
However, in some companies, and most government institutions, there’s an alternative, more traditional date form that’s used. The alternative date form is still based on the Gregorian calendar, but represents the year relative to the current era name. An era corresponds to the reign of a Japanese emperor, so the representation of the year is made up of the era name and the number of years since the beginning of the emperor’s reign, plus one. In other words, the year in which a new emperor ascends to the throne becomes year one of that era.
Slightly confusingly, the name of the era is not the same as the name of the emperor. This system was adopted in 1868, during the reign of Mutsuhito. But the name of the era was designated as Meiji. (Just to make things more interesting, after death, the emperor is referred to by the era name, not their given name.)
So why is this even an issue for IBM Notes and Domino applications and their maintenance? Well, dealing with western style dates is easy. For any given date in the future, you can calculate and correctly display the date if you know the offset from the current date. The problem with the Japanese system is that the name of the era changes any time the emperor changes. And that happens when the emperor dies (or, as in the most recent case, upon abdication). And to make matters worse, the name of the next era is chosen by a committee at some point shortly before it begins. So for any future date, it’s impossible to know what the era name will be.
The reason this just recently became known to me is because Emperor Akihito abdicated on May 1, 2019 and was succeeded by his eldest son, Naruhito. This, of course, triggered a new era name as of May 1, which changed from “Heisei” in April, to “Reiwa” in May. And the new name was not announced until April 1, 2019, just one month before the changeover.
To cope with this situation, software manufacturers have had to make updates to the Japanese language versions of their code to properly support date formats each time the emperor changes. For example, the Unicode Consortium had to add a new character for the new era name, which necessitated a new release of the Unicode character set on May 7. And IBM, of course, had to make an update to Notes and Domino itself to support the new era name in time/date fields and columns. Not to mention date manipulation functions in LotusScript and formula language.
Sounds simple enough. Update everything to the latest version and all will be well, right? Well, those of us who have ever had to maintain (someone else’s) code will know that nothing is ever that easy. The problem, of course, is that dates are not always stored in date fields. So any date after 2019-04-30 (平成31年4月30日) that has been converted to text and stored in a field needs to be updated. Likewise any picklists that include era names or hard coded dates that are used in code have to be tracked down.
And that, of course, is where some tooling would come in handy. Fortunately, the era names in Japanese have unique characters that identify them (which is why an update to Unicode is needed). And that simplifies the job of locating all the text references to the old era name, especially if you’re using a search-and-replace tool such as Teamstudio Configurator. Configurator quickly finds all occurrences of a known string in a database and shows them in context, allowing you to step through and edit them one by one. Perfect for a situation like this.
But Japanese era names are not the only things that end up being hard coded or embedded in text fields. Server names, company names and many other strings need to be tracked down, identified and potentially updated in Notes databases.
The lesson, of course, for the rest of us is to be aware of future proofing our code and making sure that, to the maximum extent possible, we place strings that may need to be updated in configuration files or profile documents, or just code them into constants so that they can be located and updated easily. That doesn’t help of course, with code that’s already been written. If that’s a problem that sounds familiar to you, click below to learn more.