The new name just uses standard characters, but what you're probably referring to is the fact that Unicode 12.1 will have a character for the two of them compressed into one glyph.

Details: http://blog.unicode.org/2018/09/new-japanese-era.html

Compressed glyphs like that are sometimes used on paperwork and whatnot, but everyday usage just uses the standard characters.

What are the benefits of this approach compared to a ligature at the font-level?

The square / single-glyph version is only used in some / limited contexts, in most contexts (including the emperor's eventual posthumous name) heisei would be written and displayed "normally".

I'm not competent to answer that, but the "merged glyph" versions of the other four modern era names date from older encodings like EUC and shift-JIS, and are presumably in unicode for compatibility. So the rationale for adding a new one may just be extending that set.

It's a combination of two existing characters, the rei as in meirei/命令 (order, command) and wa as in heiwa/平和 (peace, harmony). No new characters need to be reserved.

Also, this seems to be the first time that Japanese Royal choose the kanjis from their classical literature[1] instead of Chinese literature.

[1] https://en.wikipedia.org/wiki/Man%27y%C5%8Dsh%C5%AB

Rei, 令, in this case means 'good, fortunate', not command.

Huh, according to Jim Breen's dictionary (http://nihongo.monash.edu/cgi-bin/wwwjdic) 'good, fortunate' is '礼' (rei). '令' (rei) is listed as 'command, decree'. The official character that is being used is '令'.

Is there some rule or convention that explains why 令 means 'good, fortunate' here? Is it due to the usage in the 7th century poetry that is referenced in the article?

Even though there's an explanation, I've seen a bunch of negative reaction to the name from Japanese people online because of the association with "command", also linking it to the current prime minister and his relatively militaristic politics.

Interesting; came across this Twitter thread with a fairly detailed analysis.

https://mobile.twitter.com/nick_kapur/status/111270395164693...

In this particular case, '令月' means[1], a good month.

https://kotobank.jp/word/%E4%BB%A4%E6%9C%88-660939

If we have to trace back even further, it can date back to the ancient Chinese classic, the Classic of Poetry, where it is being used as good/respectful:

https://baike.baidu.com/item/%E4%BB%A4%E9%97%BB%E4%BB%A4%E6%...

The namers can publicly claim it to mean one thing while privately intending to be another, of course.

In case of Chinese characters, they can be interpreted under different context, I agree.

Unless you do mind reading this is all a matter of interpretation. There is no single meaning.

> Are there any developers with Unicode experience able to comment on this? I know the character for Reiwa has been reserved but I’m unsure if programmers are familiar with Y2K-esque bugs that could happen.

They create a brand new character for the era names? I find that a little hard to believe, because Wikipedia [1] already has the Reiwa era listed and my computer has a font that can display the kanji for it.

[1] https://en.wikipedia.org/wiki/List_of_Japanese_era_names

http://blog.unicode.org/2018/09/new-japanese-era.html was posted here yesterday, but the short answer is that the era can be referred to using two existing characters (for the current era: 平成) or with one new combined one (㍻). Wiki is using the former, so it doesn't need software support.

Aside from the new combined glyph, One potentially major issue is that the character 令 exists in two locations in Unicode: U+4EE4 and U+F9A8. The latter is a compatibility variant, and depending on the how smart the text processing code used is, it may or may not be considered equal to the former.

Hence, that's now one more thing to test and work around for the poor engineers working karoshi hours, only given one month to implement changes on and test the ungodly numbers of computer systems all around the country.

Really, this one-month compromise between conservatives and engineers was pretty much the worst possible result: too short to work with any breathing room, too long to throw up hands and abandon the idea of implementing it in time.

$ echo "令和" | hexdump -C

00000000 e4 bb a4 e5 92 8c 0a |.......|

00000007

Obviously the individual kanjis are reserved in CJK plane. But how is it related to Y2K-esque bugs?

Because this stuff is hardcoded into the standard library (at least in Java I know it is) and I assume it's the same for other things.

For example any dates in the future like 2020 will show up wrong. Where it ought to be reiwa 2 it will be Heisei 31 which doesn't even exist.

Heaven forbid you were doing something crazy like matching on strings for the date etc you could get into a world of hurt.

Mostly though you always work with real, actual dates and use the standard library support for the Japanese era date to calculate outputs for display only. Mostly it just means there are a few forms/invoices out there with a non-existent date on them but oh well.

Heisei 31 is this year. Heisei 32 and above are the ones that don't exist.

Thankfully I don't live in Japan and have to deal with that system on a daily basis.

It's been thirty years since anyone has to touch that code.

Some systems are even still on the previous era (shōwa). Some may even hit a Y2K-like problem in 2025 (shōwa 100).

I'm now imagining some kind of action movie where the emperor lives too long and a band of programmers have to assassinate them lest their code breaks.

Isn’t Reiwa 1 also this year?

It's both - dates through April 30 are Heisei 31, and dates from May 1 are Reiwa 1, is the official take.

Well, I don't foresee that causing any bugs.

Bugs of that type should have been worked out long ago; it is not the norm for the era change to coincide with the new year.

It is not the norm to reset your date system every 30 or so years.

...yes it is?

From May 1st onwards, yes.

Heisei 31 April 29, Heisei 31 April 30, Reiwa 1 May 1, Reiwa 1 May 2, etc.

A special character of the two kanji are combined into one for official document use. This has been reserved at U+32FF.