The Japanese Calendar’s Y2K Moment | Hacker News Reader

The Japanese Calendar’s Y2K Moment

blogs.msdn.microsoft.com

107 pointsbeefhash44 comments

As a taxpayer in Japan, I want the government to stop worrying about this inefficient calendar system and fully adopt the Western calendar everywhere.

That said, I read the people's justifications are similar to those who favor the Fahrenheit system in the US. They say the scale is close to their everyday feel (under the current system, each era is roughly equivalent to one's lifespan) than 4-digit numbers, and therefore more "human". Their emotional attachment defies rationality.

You can fight back by cramming two extra digits into any paper form demanding you express years in this manner.

https://en.wikipedia.org/wiki/ISO_8601 is elegant because it solves the US/UK date ordering conflict and simultaneously renormalizes for most-to-least significant (which has been standard in the Far East for thousands of years). Depoliticizing time is a good thing(TM). See also: use of BCE suffix in dates: https://en.wikipedia.org/wiki/Common_Era and the total mess that is attempting to express to a human the actual meaning of an entry in the TZ database. http://tz.iana.narkive.com/QuK9m7tT/tz-proposal-for-a-modern...

Defies rationality? It's perfectly rational to prefer a system of measurement that is more meaningful to you.

We definitely need to fix the issue of human lifespans being mostly limited to two digits.

Two things that are missing from the article:

1) because of this problem, the government is considering keeping Heisei for a while after the emperor steps down https://minhan.jp/4599 (in Japanese)

2) the Japanese calendar (specifically the year) is used in some official documents and formalities, but in daily life people mostly use the Gregorian calendar. If you ask a bunch of Japanese people what Heisei year is now, I bet a significant percentage of them won't remember. I've worked as a software engineer in Japan for over 10 years and I've never had to deal with Japanese calendar years.

If you have to deal with larger systems that interface with finance or government orgs, you'll end up needing to work with these numbers though.

I've heard that there's not a legal framework for using Common Era dates in certain contexts, which...apparently matters? I've also heard that the gov't even has regulations for enforcing usage, but can't find a reference on that. One could think that it's merely an interface problem but if the database asks for Heisei the easiest thing is to outsource the CE -> Heisei transition to the person filling out the form.

The Japanese driving license expose people to the Japanese calendar years, and they are renewed every 3 or 5 years. Mine expires in 平31. So technically, it might even expire in year 1 of the new era (it expires in July).

So what happens if an emperor dies unexpectedly? Does all Japanese calendar aware software break?

From centuries ago emperors could decrete new eras, and in the last centuries it was rationalized as one emperor reign = one era. So when the new emperor will be enthroned, he will take its emperor name that also will become the era new era name. How the previous emperor exit the throne (death or abdication) is irrelevant.

He's talking about the software patching issue. If the emperor dies today, how do you update all software to understand the name of the new year?

The succession itself is pretty straightforward; people will see it on the news and memorize the new name immediately. Software is more difficult, though.

This is not really a new issue. Daylight savings time rules change, leap seconds are added and removed. Most software doesn't care because someone will notice and change the clock, or NTP notices that your clock is a second slow because you forgot the leap second and it moves it forward. But being a second or an hour off is a slightly different problem than not knowing what the current year is called, or how to add/subtract years.

Software that wants to be resilient to any of these changes simply uses a timebase that doesn't have leap seconds, daylight savings time, or the year changing... but users want to see "Heisei 30" and not something that is 37 seconds ahead of what their wall clock says the time is. Formatting the time is still an issue no matter what timebase you use.

> If the emperor dies today, how do you update all software to understand the name of the new year?

I understood the question but it is pointless: how can you expect software to be magically patched if no update mecanism is in place? Some will, others won’t.

You understood the literal question, but not the motivation and thus not the real question.

That‘s what Microsoft is users helping to find out.

As the article states, for most of computing‘s history (and certainly all of consumer‘s computing history) there hasn‘t been an era change, yet.

In the sense that they'll show dates wrong, yes, though one could imagine the following era might start a few months after the death.

But essentially, software (and printed calendars!) will start showing dates with years "overflowing" the era.

Actually, it'll start just few days after the death. When last emperor died on 1989-01-07, that was the end of Syowa 64, then Heisei 1st (called Gan-nen 元年 instead of 1st) started on 1989-01-08.

Committee starts the plan of determining new era name well in advance when this is about to happen, so this is determined a several months in advance.

With this transition that taking place next year, I hear many of engineers are very annoyed for the fact they are withholding announcement of this just a month before it is changing, for the publicly stated reasoning of to "not ruin the surprise."

It's also worth noting this is the first era transition while computer systems are basically everywhere.

Actually, back in Showa-Heisei, there were plenty of the computerized system existed already. Many of these system, where they could not be patched, is "assuming" the system is still in Showa. (So the system thinks this year's Showa 93)

They will see Y2K like problem in 2025 (Showa-100) if these systems are still active somewhere (as they may not handle >99) and to less extent, same thing may happen in 2088 (Heisei-100)

I'm thinking their tendency of ground-up development of those internal systems in Japan would make this a lot more complicated.

Anything that isn't used to produce some sort of official documents should be using Western-style dates anyway. Also month, day and time stay the same regardless of the era. Only the year number gets reset to 1.

”Western-style“ dates don’t really exist: most countries use DMY, US for reasons unknown has gone with MDY, and Japan and China have officially standardised on ISO-8601 (YMD): https://en.wikipedia.org/wiki/Date_format_by_country

A Western-style date refers to a date based on the Gregorian calendar, regardless of how one orders the individual components of a date.

I suspect "Western-style dates" was meant to refer to the Gregorian calendar rather than the format used to represent a date on that calendar.

ISO-8601 only really applies to the Gregorian calendar.

YMD is the only sane format. When you sort, you can sort by the year, followed by month and day. I do this a lot with folder names or log file names in directories, file system creation/modified dates don't always match reality. e.g. a folder named 2018-01-07 is entirely readable to anyone who looks at it, but at the same time easily sorted.

And DMY is the only sane human-readable format for LTR languages.

When you write the time, do you put the minutes to the left or the right of the hour?

I think that the timescale on which humans live matters here. The year field doesn't change often, so for the everyday usecase it's kind of redundant – it's probably the current year, so specifying it first is kind of noisy[1]. But on the scale of hours, it's the minutes that are noise, because you likely care more about the hour. So I guess the most ergonomic ordering depends on the usecase.

[1] This could be different if you're, say, browsing an archive. Still, if I'm looking at a thread from 2005, that context is in my head, and I don't need to be constantly reminded of that by seeing 2005-XX-YY.

In English, at least, it used to be that a document such as a letter would begin with a date indicating when it was written, and then for dates ±1 month from that date would express relatively, like so:

* "The 10th instant" / "10th inst." = tenth day of current month indicated in date of document

* "The 10th ultimo" / "10th ult." = tenth day of month preceding the one indicated in date of document

* "The 10th proximo" / "10th prox." = tenth day of month following the one indicated in date of document

Arabic often writes dates and phone numbers from left to right. I can't speak for other RTL langauges but I can't see DMY being a problem for most people around the world. Ultimately, non-English speakers have to learn English to write code and if they want standardised dates across their systems they should use the standard of the language they're writing in.

Okay, there's what the date _is_ (on what calendar, what system of reckoning dates?), and there's how you serialize it.

(month: July; day-of-month: 2; year: 2018) -- can be serialized (written) a variety of ways, ISO-8601 Y-M-D being one of them.

However (month: July; day-of-month: 2; year: Heisei 30) is a different story, not just a question of serialization.

(month: Tamus; day-of-month: 19; year: 5778) -- yet more different.

(month: Shawwal; day-of-month: 18; year:1439)

"Western style dates" above means "the Gregorian calendar". Yes, how you write or serialize it for machine-parsing can be another issue. But dates on _another calendar altogether_ is a bigger one. Although the Japanese calendar that just has a different name for the year, but the months and dates and beginning and ends of the year are synchornized with gregorian -- not as big as the "Hebrew" or "Islamic" calendars which have entirely different months and years with boundaries unrelated to the gregorian calendars'.

"Western-style dates" is a literal translation of "西暦(seireki)", which people use to refer to the Gregorian calendar in Japanese.

Thanks, that adds the necessary context.

The Heisei era started in 1989 with the death of Hirohito (posthumously named Showa). Since then, there was no unexpected death of emperors. Modern software has never been put to the test.

Taiwan had a similar problem just a few years ago: https://en.wikipedia.org/wiki/Y1C_Problem

Did they mess up character encoding, or are there really a bunch of question marks in the registry.

From the article:

> The last value "2019 05 01" contains the temporary information "？？_？_??????_?"

Now I'm not sure if the thing contains a bunch of question marks (in two different fonts, no less) or if somewhere (the original poster, the blog, your OS, hacker news, my browser, my OS) the character encoding got dorked up.

For reference, here's what I see: https://imgur.com/a/VdcaQ0r

The fact that there are unicode "Fullwidth Question Mark"s as well as what appear to be normal question marks make me thing there still is an encoding issue.

As possibly should the fact that the Klingon in the title is greeked in the header. (-:

I didn't realize the article is old and the changes are already available in an updated Win10 installation.

It is indeed as it shows in the article. For reference: https://imgur.com/a/2tiYJ1w

Honestly at this point if you are not storing dates in UTC form and transforming it in order to get to the Japanese calendar format, you are doing things wrong. The emperor is not eternal (yeah, I know, blasphemy) and the end of the era is totally expected.

What does it mean to store a date in a time zone (such as UTC) form? Do you mean store dates as timestamps of UTC midnight on that date? Even this isn't a storage format: do you mean a big-endian Java epoch milliseconds timestamp, ISO 8601 text, or some other format?

I think you mean they should be using some representation of a Gregorian calendar date, be it text or binary.

In any case, it sounds like they should probably have something analogous to the timezone database for converting between various calendars where the mapping can't be determined in advance.

That brings up a good question: in the Islamic calendar, the new year doesn't start until reception of a reliable lunar observation by a Muslim. How do they get around this in strict Muslim countries? Do they have a second concept for "year" that's identical to the year except in the observational requirement and therefore can be treated the same, but because of name doesn't break the religious law? I presume they don't go through the trouble of creating a low-latency network to distribute the start-of-year signal and make timestamp-to-string routines block near the year rollover until they've seen the signal.

Well look at how DST regulation changes (about one worldwide every six months) are handled: tzdata is the most underrated project around. I would not be surprised if islami calendars relied on something similar. In their case it is easier as there are (to my knowledge) not several islamic zones observing different rules.

https://en.wikipedia.org/wiki/Tz_database

Yes, that's the Wikipedia link to the timezone database I mentioned.

But, latency is the issue. The year doesn't officially change until a Muslim makes the necessary lunar observation on the first evening of the new year. You can't pre-calculate a human observation, so to be in strict compliance, you'd need an efficient way to rapidly distribute the observation.

I'm sure that in practice, pre-calculation is almost always used. My question is how this is rationalized in more strict conservative Islamic countries, (or less likely, how they avoid using pre-calculated start of the new year).

I would guess that the people tasked with observing the new moon have a sense of responsibility and know on which day they are expected to observe it, so they do the right thing. It's easy enough to avoid observing the new moon too early: just don't look at the sunset on the day before. Making sure you do observe the new moon on the right day is harder, but if you have several observatories you can probably manage it without self-deception almost every time.

ok selfish question but I fly into Tokyo on 28 April - Does anyone expect any disruptions around the 30th?

Reply on news.ycombinator.com