'Japan's millennium bug' ahead of Akihito's abdication(theguardian.com)
theguardian.com
'Japan's millennium bug' ahead of Akihito's abdication
https://www.theguardian.com/technology/2018/jul/25/big-tech-warns-japan-millennium-bug-y2k-emperor-akihito-abdication
98 comments
How pervasive is the Japanese calendar in computing actually? I suppose most programs calculate all dates internally using UNIX timestamps or UTC and only convert that to Japanese dates for display purposes. Anybody has any experience with this?
Yes, I have been doing software development in Japan for the past decade.
Of course you are right that no sane person would contemplate this calendar for any purpose other than user-facing display, and even then only where it is absolutely required.
But the insane WTF thing is that it does still seem to be widely required on any kind of financial document. Expense reports, salary statements, that kind of thing. All my banks use this format (and also SJIS text encoding when I download my data (T_T)...)
There are also lots of internal processes^W^W Excel spreadsheets in active use that expect these values so I've seen more than one program that converts 2013 to "H.25"... and it's literally impossible to represent a future date, since we don't know when the emperor might die, even if we have a projected abdication date.
I can't be too smug about it, since I'm American (miles and feet, anybody?) but it is... objectively non-optimal.
Of course you are right that no sane person would contemplate this calendar for any purpose other than user-facing display, and even then only where it is absolutely required.
But the insane WTF thing is that it does still seem to be widely required on any kind of financial document. Expense reports, salary statements, that kind of thing. All my banks use this format (and also SJIS text encoding when I download my data (T_T)...)
There are also lots of internal processes^W^W Excel spreadsheets in active use that expect these values so I've seen more than one program that converts 2013 to "H.25"... and it's literally impossible to represent a future date, since we don't know when the emperor might die, even if we have a projected abdication date.
I can't be too smug about it, since I'm American (miles and feet, anybody?) but it is... objectively non-optimal.
Canada isn't much better re: feet, miles. Things are officially metric, but because of proximity to the US and inertia, half of everything is still standard. Buying construction supplies and consumables? All in US units. People talk about square footage of condos, buy carpet in square feet, all fasteners are in US units. But gasoline is sold by the liter. People know how tall they are in feet and inches, not cm. Everything is mixed up together.
Interesting. UK is also weird: food is weighed in metric units, people in imperial; Drinks bought in supermarkets are measured in metric, pubs use imperial (by law in both cases, IIRC); Distances on signs can be meters or miles, both initialised as “m” (context being the only clue); fuel is sold by the litre, fuel efficiency is miles per gallon.
Beer and cider is sold in pubs in imperial pints (bigger than US pints), but wines and spirits are sold in milliliters.
See https://www.gov.uk/weights-measures-and-packaging-the-law
See https://www.gov.uk/weights-measures-and-packaging-the-law
Good point, I’d forgotten wine and beer were different. I wonder what further examples of mixed up units the UK has?
Well there is a tendency to still use Fahrenheit during summer like "it's in the 80s", and "it's in the 90s" this month, but most use Celcius for winters when it gets below freezing. There must be a grey area in the 50s and 60s F. Both approaches often seen in headlines. :)
I'm a physicist and I still feel compelled to die on the following hill, re: Fahrenheit---it just maps better to human perception:
30s: Wear a heavy coat
40s: Wear a light coat
50s: Wear a jacket
60s: Wear a hoodie
70s: Wear a t-shirt
80s: Wear shorts
30s: Wear a heavy coat
40s: Wear a light coat
50s: Wear a jacket
60s: Wear a hoodie
70s: Wear a t-shirt
80s: Wear shorts
Works in C too:
-ve Don't go outside
0s Wear a coat
10s Wear a jacket
20s Wear a t-shirt
30s Don't go outside
-ve Don't go outside
0s Wear a coat
10s Wear a jacket
20s Wear a t-shirt
30s Don't go outside
-40s too cold
-30s cold
-20s February
-10s beanie optional
-0s can't store non-alcoholic drinks on the balcony
+0s wear waterproof boots
+10s no need to wear a jacket
+20s don't wear more than a t-shirt
+30s can't sleep since my apt. has no AC
Fixed that for northeners you insensitive clod.
-30s cold
-20s February
-10s beanie optional
-0s can't store non-alcoholic drinks on the balcony
+0s wear waterproof boots
+10s no need to wear a jacket
+20s don't wear more than a t-shirt
+30s can't sleep since my apt. has no AC
Fixed that for northeners you insensitive clod.
What a brilliant comment! In fact, I'd even say it's over 9E+3 photons/s/mm^2/mrad^2/(0.001*Δλ)
c is just easy because 0 is the freezing point.
Miles per Imperial gallon.
don't some parts of Europe also use decilitres for beverage packaging? I've seen bottles that are like "75dl", and it took me a few minutes to clue in.
That would be centiliters, for example, wine is most commonly sold in 75cl bottles. Millilitres is also a common unit for smaller quantities in e.g. cosmetics.
Right! I actually meant centiliters - it's been a few years. But a commenter below mentions deciliters are a thing as well. What a crazy world :)
At least in some parts of central Europe it is common to buy beverages per decilitre and meat by dekagrams.
750 Liters would be a very large beverage! A typical keg of beer is only around 59 liters.
1dL = 0.1L
My bad, thought the d was for deca, not deci.
I'm in the US and although I spent some time in Canada I am for the most part not used to seeing the metric system used day to day. My metric system knowledge basically is what I remember from elementary and middle school.
I'm in the US and although I spent some time in Canada I am for the most part not used to seeing the metric system used day to day. My metric system knowledge basically is what I remember from elementary and middle school.
Any movement to slowly unify the spreads?
but to further confuse things, your height on the driver's license is in cm, not ft-in. and while some imperial units are widely used, I've never heard anyone using yards or gallons, and very rarely miles. I find it rather adorable.
concrete pours are still priced by the cubic yard (such as if doing a radio tower foundation or any commercial project).
a lot of construction related things that are priced by the cubic volume are still in cubic yards.
a lot of construction related things that are priced by the cubic volume are still in cubic yards.
Yeah
I suppose they like using lbs and sqft as $/lb is smaller and sqft is a bigger number than sqm (and of course the inertia which I prefer calling "being lazy")
It is definitely ridiculous
I suppose they like using lbs and sqft as $/lb is smaller and sqft is a bigger number than sqm (and of course the inertia which I prefer calling "being lazy")
It is definitely ridiculous
It's sad this date system is there for no reason today. Systems never like it and neither do people. I rarely use it and it's mostly bank related but every time I do, I look it up on Google to make sure I remember the number right. This needs to be dropped.
Interestingly, sometimes the system is used for future dates. For instance, my drivers license expires in September of H.31, which I guess will never happen now.
Does this imply that the driver's license becomes invalid and must be replaced with one in the new date system?
Real question
Real question
Or -- perhaps more intriguingly -- given that the date in question will never occur, is it valid until the end of time?
Philosophically it's a rather fun question, but practically they'll probably just honor it until the corresponding date of the new era.
Philosophically it's a rather fun question, but practically they'll probably just honor it until the corresponding date of the new era.
It will stay valid. Consider having have to replace millions and millions right after the swap, it will be chaos. The system is simply stupid, not even citizens want it.
Coming from a platform which stores time as local times and no time zone (also needing to handle SJIS text formatting on occasion) I wouldn't consider it a common problem, but the amount of code which doesn't handle dates that I with with is surprising high. I wouldn't be shocked if much of Japan's code has similar oddities (I suspect future dates will have a special comparison logic added for the overlap which results)
Even though it's only user facing you have to remember it's facing Japanese users. They are an extremely fussy demographic to deal with. I worked on enterprise billing systems in Japan before. I can imagine how not fun it is to be dealing with this issue right now.
I was thinking this exactly. Not much of a problem for data, more of a problem for display of the data. A good stop-gap until they get enough information about the new era would be to just display the dates in UTC for a while or something.
I mean, unless they're storing the date/time in the database as a string, formatted for Japan's locale. Then they're screwed, kind of. I mean even then, it could be fixed with a stored procedure within an update statement.
I mean, unless they're storing the date/time in the database as a string, formatted for Japan's locale. Then they're screwed, kind of. I mean even then, it could be fixed with a stored procedure within an update statement.
As much as using UTC would be better, I suppose for many that will not be an option if they are accustomed to Japanese dates. I mean, I got flak in work because I was writing dates (as in, written on printed paper) in the ISO-8601 format and apparently the administration in France does not understand that.
I'm sure some unfortunate developer in Japan has made this mistake as I've seen datetimes stored as strings in America.
There's also probably logic in UIs somewhere that uses the string representation for something more critical than you'd expect.
There's also probably logic in UIs somewhere that uses the string representation for something more critical than you'd expect.
There are all kinds of random places where this has potential to show up. For example, some backend process breaking (or worse, silently discarding data) because of validating dates in incoming data from another system as a string regex that expects the old era symbol.
I don't think that's the problem; I think that's the one thing that's not a problem. Monotonic time is not that hard. The hardest thing about it is just convincing programmers to use it, and making sure your libraries use it properly. I don't want to say it's trivial, but it's not that hard once both you and your code base internalize "convert everything to internal UTC representation as quickly as possible, convert to local time as late as possible on the way out".
It's everything else that's a problem. It's the places where you input the Japanese time, and there's an era that the code has never heard of for some old system. There is no way for that system to even conceivably handle it without some sort of update, at least a database update. They're talking about creating a new character for the era, which literally no system on Earth can currently use because it doesn't even exist yet, and, again, anything old that can't be updated can't conceivably display it correctly. They might be able to display it as the individual characters, but they still won't know that's a date, or that they have to. As mipmap04 says, it's where Japanese dates were stored as a string or something, because goodness knows I've seen enough US dates stored as strings.
And inferring from the article that the tax authority is going to extend the old era, I assume that at the very least a good chunk of the government works on Japanese dates, so it's going to be important not to, say, print tax forms that have � in the date, etc.
It's everything else that's a problem. It's the places where you input the Japanese time, and there's an era that the code has never heard of for some old system. There is no way for that system to even conceivably handle it without some sort of update, at least a database update. They're talking about creating a new character for the era, which literally no system on Earth can currently use because it doesn't even exist yet, and, again, anything old that can't be updated can't conceivably display it correctly. They might be able to display it as the individual characters, but they still won't know that's a date, or that they have to. As mipmap04 says, it's where Japanese dates were stored as a string or something, because goodness knows I've seen enough US dates stored as strings.
And inferring from the article that the tax authority is going to extend the old era, I assume that at the very least a good chunk of the government works on Japanese dates, so it's going to be important not to, say, print tax forms that have � in the date, etc.
UTC is good but not enough; it may still bite you in the behind.
What's the time difference between these 2 timestamps:
So then your next option is to use TAI (international atomic time). Of course for most applications, this extra/missing leap second doesn't matter.
And that's the crux of the issue. Given a level of abstraction, we're comfortable with a sufficient level of accuracy because it's the most convenient for 99% of the use cases. It takes a widely adopted tooling to bump the abstraction to a more accurate representation. In UNIX land, going from YYYYMMDDHHMMSS to a number of seconds has been a huge improvement. It's comfortable to use because all environments have the tooling to go back and forth from seconds to human-readable dates.
Try to use TAI and you start feeling a lot more lonely (ever tried to read logs timestamped in TAI? fun!) Most OS and server processes are used with the tradeoff that it's not a big deal if we have 2 events spaced a second apart and both timestamped the same (1483232399), since it's not that frequent.
What's the time difference between these 2 timestamps:
2016-12-31 23:59:50 UTC (unix time 1483232390)
2017-01-01 00:00:10 UTC (unix time 1483232410)
So then your next option is to use TAI (international atomic time). Of course for most applications, this extra/missing leap second doesn't matter.
And that's the crux of the issue. Given a level of abstraction, we're comfortable with a sufficient level of accuracy because it's the most convenient for 99% of the use cases. It takes a widely adopted tooling to bump the abstraction to a more accurate representation. In UNIX land, going from YYYYMMDDHHMMSS to a number of seconds has been a huge improvement. It's comfortable to use because all environments have the tooling to go back and forth from seconds to human-readable dates.
Try to use TAI and you start feeling a lot more lonely (ever tried to read logs timestamped in TAI? fun!) Most OS and server processes are used with the tradeoff that it's not a big deal if we have 2 events spaced a second apart and both timestamped the same (1483232399), since it's not that frequent.
I wrote a TAI parser library for Go (tai64/tai64n), and I agree that TAI timestamps are... terse..
Nice format though, other than readability. ;)
Nice format though, other than readability. ;)
Wait: are you saying that Unix time does not take into account the leap second?!
Correct. POSIX time is defined as number of seconds per (non-leapsecond) day times number of complete day since the epoch, plus the number of seconds in the current day.
POSIX timestamps get weird around leap seconds. Time stamps get repeated, subtraction returns incorrect results, and so on.
POSIX timestamps get weird around leap seconds. Time stamps get repeated, subtraction returns incorrect results, and so on.
If you use Java and the java.time API they added in the last release, you're covered for all of this.
https://docs.oracle.com/javase/8/docs/api/java/time/Instant....
In this segment, the Java Time-Scale is identical to UTC-SLS. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread equally over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day.
Java apps don't use UNIX time, they use something very similar called the Java timeline which is basically the same as UTC but leap seconds are smeared.
The java.time API is really incredibly thorough. It does of course have support for Japanese dates:
https://docs.oracle.com/javase/8/docs/api/java/time/chrono/J...
The type system and runtime checks also catch subtle errors like assuming "one day from now" and "in 24 hours from now" are the same thing.
https://docs.oracle.com/javase/8/docs/api/java/time/Instant....
In this segment, the Java Time-Scale is identical to UTC-SLS. This is identical to UTC on days that do not have a leap second. On days that do have a leap second, the leap second is spread equally over the last 1000 seconds of the day, maintaining the appearance of exactly 86400 seconds per day.
Java apps don't use UNIX time, they use something very similar called the Java timeline which is basically the same as UTC but leap seconds are smeared.
The java.time API is really incredibly thorough. It does of course have support for Japanese dates:
https://docs.oracle.com/javase/8/docs/api/java/time/chrono/J...
The type system and runtime checks also catch subtle errors like assuming "one day from now" and "in 24 hours from now" are the same thing.
IIRC google and the like solve this using a special time routine in their kernels that literally just spread the second out across the day. It's close enough.. and legal will still accept it for auditing requirements.
>"convert everything to internal UTC representation as quickly as possible, convert to local time as late as possible on the way out".
That's not a good approach to use for future events.
That's not a good approach to use for future events.
I should have qualified that with an exclusion for recurring and future events. Identifying present and past times, which is the majority case, is not that difficult. Future times is one of those cases where the availability heuristic fools you; you can readily think of cases where it is a concern, but it is the clear minority of things that have to deal with time.
> I don't want to say it's trivial, but it's not that hard once both you and your code base internalize "convert everything to internal UTC representation as quickly as possible, convert to local time as late as possible on the way out".
It's really not that easy. Recurrences and durations are the killers.
When you schedule that meeting for 4:00PM every Tuesday, what happens when daylight savings time kicks in?
It's really not that easy. Recurrences and durations are the killers.
When you schedule that meeting for 4:00PM every Tuesday, what happens when daylight savings time kicks in?
> tax forms that have � in the date
Just make � the official symbol of the new era :)
Just make � the official symbol of the new era :)
I've just been on a 3 week trip to Japan and didn't see traditional Japanese dates used anywhere except on museum exhibits. Train tickets, bus tickets, hotel check-in / out dates, credit card receipts, tickets for various attractions etc. all displayed the date in ISO-8601 format.
It's interesting to ponder, but the traditional date format seems to have fallen out of use (probably with the advent of the computer era) and I genuinely don't think that this will be a problem.
It's interesting to ponder, but the traditional date format seems to have fallen out of use (probably with the advent of the computer era) and I genuinely don't think that this will be a problem.
Probably not with the tourist , though all my JR ticket I have are listed with traditional date though -- maybe they issued it with A.D because of you are tourist. Other tickets seems to be mixed though.
For example, of documents I have laying around my desk right now:
Alien card: A.D / Student card: A.D. / My number card (like US SSN): Traditional / Insurance card: Traditional / Water bill: Traditional / Electricity bill: Traditional (this one doesn't even tell you that it's traditional, it just say 30-07-xx) / Monthly health insurance bill: Traditional / Gas bill: A.D.
So it is pretty much in heavy use.
For example, of documents I have laying around my desk right now:
Alien card: A.D / Student card: A.D. / My number card (like US SSN): Traditional / Insurance card: Traditional / Water bill: Traditional / Electricity bill: Traditional (this one doesn't even tell you that it's traditional, it just say 30-07-xx) / Monthly health insurance bill: Traditional / Gas bill: A.D.
So it is pretty much in heavy use.
Alien card? Do you mean the zairyu card?
JR definitely produces different tickets depending on whether you used the machine in English or Japanese. (Or depending on what the station attendant thought would be most convenient for you; they can pick the output format and I've gotten both.)
You'll see more in banks and sometimes registering papers and I admit I hate it because I don't remember it as I use it maybe only once or twice a year and it provides no benefit to anyone.
If you are there to live rather than to tour you will find that the traditional date format is pervasive in daily life. Banking, legal documents, etc.
I lived in japan for a few months and all the dates for the immigration, housing, etc... in official papers had to be written in the traditional format.
At least train tickets show dates in Japanese era years.
Like this one for instance: https://blue-works.com/jprail/wp-content/uploads/2010/07/res...
The date at the bottom left is April 26th of the year Heisei 22 (so 2010)
Like this one for instance: https://blue-works.com/jprail/wp-content/uploads/2010/07/res...
The date at the bottom left is April 26th of the year Heisei 22 (so 2010)
I work on a large enterprise software product. We support Emperor dating (since the long gone legacy product from the late 1970s), and it is used, I just don't know how widely or for what reasons.
It's seems silly to compare it to the y2k problem, aside from the bit at the end of the article:
Many older computers, with aspects dating back to before the end of the Shōwa era in 1989, have never been updated to reflect the new era, and still think the year is Shōwa 93. That means Japan could face another mini Y2K problem in 2025, as those systems attempt to tick over to a three digit Shōwa year they can’t cope with.
The real problem with y2k was the amount of compiled code depending on two-digit years. All those conditionals looked exactly like any other integer comparison.
Many older computers, with aspects dating back to before the end of the Shōwa era in 1989, have never been updated to reflect the new era, and still think the year is Shōwa 93. That means Japan could face another mini Y2K problem in 2025, as those systems attempt to tick over to a three digit Shōwa year they can’t cope with.
The real problem with y2k was the amount of compiled code depending on two-digit years. All those conditionals looked exactly like any other integer comparison.
It's much like Y2K if you think of the emperor as a digit in a unique numbering system (empero-decimal?)
Why can't the Unicode consortium not reserve codepoints for the next 10-50 eras and simply wait with filling in how it should look and what to be called?
As jerf pointed out [0], you can do that but once you print that unknown symbol, the Unicode consortium can't really do much.
Also, you can't just say "well, next era begins on September 1st 2054, so let's write that in our date calculator" - precisely because you don't know when an era begins or ends before it's close.
[0] https://news.ycombinator.com/item?id=17609063
Also, you can't just say "well, next era begins on September 1st 2054, so let's write that in our date calculator" - precisely because you don't know when an era begins or ends before it's close.
[0] https://news.ycombinator.com/item?id=17609063
Some character properties need to be immutable and can't be set correctly until the committee has an actual character to analyze.
I sometimes wonder if Unix clock running out in 2038 is going to be our only hope to solve the Great IoT DDOS war of 2030s? :)
We'll all be reliving the 70's.
Pretty sure they'll figure it out. There will just be a period where both dates are used. It'll be a little messy, but they'll survive. Definitely learned something from the article though!
How are the eras named? This will be the end of the Heisei era. I grew up in the Showa era (apparently.)
The Japanese emperor picks a regnal name when he takes the throne, just like the Pope.
The name is actually the name of the emperor, not the name of the era. In Japan, nobody uses the emperor's birth name; they just use the regnal name. For example, nobody in Japan says "Hirohito"; they refer to him as "Emperor Showa" instead (though nobody calls Akihito "Emperor Heisei" now, because it's considered rude to refer to the living emperor by name... he's just "His Majesty, the Emperor").
Note that this wasn't the case until the 19th century. Until Emperor Meiji (Mutsuhito) took the throne in 1867, the name of the emperor and the name of the era were completely decoupled, and the emperor would just arbitrarily start eras whenever he felt like it. Meiji changed all this and standardized Japan on a one-emperor, one-era system. And in 1979 (!), it actually became law.
The name is actually the name of the emperor, not the name of the era. In Japan, nobody uses the emperor's birth name; they just use the regnal name. For example, nobody in Japan says "Hirohito"; they refer to him as "Emperor Showa" instead (though nobody calls Akihito "Emperor Heisei" now, because it's considered rude to refer to the living emperor by name... he's just "His Majesty, the Emperor").
Note that this wasn't the case until the 19th century. Until Emperor Meiji (Mutsuhito) took the throne in 1867, the name of the emperor and the name of the era were completely decoupled, and the emperor would just arbitrarily start eras whenever he felt like it. Meiji changed all this and standardized Japan on a one-emperor, one-era system. And in 1979 (!), it actually became law.
This seems to be common misconception. Akihito is NOT "Emperor Heisei" now. The name is always given posthumously (though it is yet to be seen for Akihito if he will be named immediately after abdication or also posthumously.
It is severely rude simply because it implies that said person is already dead.
It is severely rude simply because it implies that said person is already dead.
Thanks. This contextualises something for me. In 1989, I asked a Japanese friend about Hirohito - his death or something - and the guy just couldn't understand what I was talking about. My friend's English wasn't very good and my pronunciation of the name possibly also didn't help.
Funny it needs to be considered rude. I don't know the use of the emperor system except it's wasting our taxes and a huge land.
Is it generally true that, if the Emperor has to refer to himself by name, he'll use his birth name?
The one case I've seen that seems this way is that the first author of this paper on fish genetics [1] is listed as "Akihito".
[1] https://www.ncbi.nlm.nih.gov/pubmed/26475939
The one case I've seen that seems this way is that the first author of this paper on fish genetics [1] is listed as "Akihito".
[1] https://www.ncbi.nlm.nih.gov/pubmed/26475939
"The Imperial Residence, 1-1 Chiyoda, Chiyoda-ku, Tokyo 100-0001, Japan."
Is his phone number 001-0000-0001?
Is his phone number 001-0000-0001?
Maybe 090-0000-0001. (090 signifies a mobile phone number)
Oh wow, it must be insane to be co-author to the emperor!
From the outside it's a weird juxtaposion of a traditional, old (from a European point of view) system of state and an everyday modern way of conducting scientific research. You'd just not expect this kind of contact, somehow.
From the outside it's a weird juxtaposion of a traditional, old (from a European point of view) system of state and an everyday modern way of conducting scientific research. You'd just not expect this kind of contact, somehow.
> From the outside it's a weird juxtaposion of a traditional, old (from a European point of view) system of state and an everyday modern way of conducting scientific research. You'd just not expect this kind of contact, somehow.
Well, what seems to be the most visible European monarchy outside of its own country (the British) seems to still largely adhere to the custom of the monarch (and, to a lesser extent, the close royal family) refraining from anything that looks like work (military service of the close royal family being a notable exception) outside of royal duties, which might color that expectation.
Well, what seems to be the most visible European monarchy outside of its own country (the British) seems to still largely adhere to the custom of the monarch (and, to a lesser extent, the close royal family) refraining from anything that looks like work (military service of the close royal family being a notable exception) outside of royal duties, which might color that expectation.
Prince William is a professional coast guard helicopter pilot. He has done real work in the past, at least.
> Prince William is a professional coast guard helicopter pilot.
That was among his military roles, yes; perhaps more to the point he took a paid (though his entire salary was donated) position as a pilot with the East Anglia Air Ambulance for a couple years, which I think was a bit unusual (but as it was paid work for a charity with the whole salary donated back to the charity, arguably is really a form of charity volunteer work, which probably should be listed as an exception along with military service for the close royal family.)
That was among his military roles, yes; perhaps more to the point he took a paid (though his entire salary was donated) position as a pilot with the East Anglia Air Ambulance for a couple years, which I think was a bit unusual (but as it was paid work for a charity with the whole salary donated back to the charity, arguably is really a form of charity volunteer work, which probably should be listed as an exception along with military service for the close royal family.)
So the co-authors have an Akihito Number of 1. Does anybody on the thread have an Akihito Number of 3 or less?
I (3) believe one of my friends (2) served one of the princesses (1) tea at a ceremony once when they visited Hawaii.
All of those need to publish papers with each other to qualify, probably. Maybe we can find another measure?
https://en.wikipedia.org/wiki/Erd%C5%91s_number
https://en.wikipedia.org/wiki/Erd%C5%91s_number
My grandfather was Akihito’s waiter in the 80s
And one of the princes, too. Akishinomiya F (Fumihito) is emperor's second prince.
Thanks! I knew I'd get a good explanation here. And you piqued my interest in the Meiji period - any good Japanese histories to recommend?
Donald Keene's Emperor of Japan: Meiji and His World is probably the most complete work on that period of time. It's an enjoyable but very dense read.
?
" Source: Ken Whistler
Date: July 16, 2018
Background
The UTC is now working on the Unicode 12.0 release cycle. The tentative release date that I and the Editorial Committee are working towards for that release is March 5, 2018. "
" Source: Ken Whistler
Date: July 16, 2018
Background
The UTC is now working on the Unicode 12.0 release cycle. The tentative release date that I and the Editorial Committee are working towards for that release is March 5, 2018. "
I believe it's a typo, and he means 2019.
what a fascinating article! the bits about Unicode needing to be updated and also how their legacy systems were never updated for Heisei blew my mind. Great write up!
Why not just keep counting up forever and use it like Japanese epoch time?
Starting from when, Emperor Jimmu?
> Starting from when, Emperor Jimmu?
This system actually existed but it has an association with ww2 so it probably wouldn't go over very well now: https://en.wikipedia.org/wiki/Japanese_imperial_year
This system actually existed but it has an association with ww2 so it probably wouldn't go over very well now: https://en.wikipedia.org/wiki/Japanese_imperial_year
They’ve already started with the current emperor. Basically don’t change anything is what I’m wondering about — just keep counting up.
Setting aside whatever political and cultural pressures there might be to maintain the status quo, this isn't just a measure of time, it's a measure of units of imperial reigns. What does it even signify if it doesn't roll over when a transition occurs?
> For one, Akihito has been on the throne for almost the entirety of the information age, meaning that many systems have never had to deal with a switchover in era.
The writer must be 12. The last transition, in 1989, is squarely in the middle of the information age.
The writer must be 12. The last transition, in 1989, is squarely in the middle of the information age.
The ageist comment seems unnecessary. I've been on the 'internet' since the 80s as well, but I don't think of the internet really taking off until the 90s, so I understand what the author's comment was conveying.
> The writer must be 12.
Not a useful insight. Compare to me starting a comment with something like "The parent commenter must be an octogenarian." It doesn't actually add anything to your thesis.
> The last transition, in 1989, is squarely in the middle of the information age.
I, and others I'm sure, would argue that 80s were in the earlier half of the information age, especially if we mark it not by time but by number of systems built.
Not a useful insight. Compare to me starting a comment with something like "The parent commenter must be an octogenarian." It doesn't actually add anything to your thesis.
> The last transition, in 1989, is squarely in the middle of the information age.
I, and others I'm sure, would argue that 80s were in the earlier half of the information age, especially if we mark it not by time but by number of systems built.
Dunno -- I'm still emotionally scarred from dealing with JIS, S-JIS, EUC, etc. in the early 90s. Anyone else remember Ken Lunde's fugu book....?
See also this discussion from 23 days ago: https://news.ycombinator.com/item?id=17430085