'Japan's millennium bug' ahead of Akihito's abdication
theguardian.com
theguardian.com
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.
There's also probably logic in UIs somewhere that uses the string representation for something more critical than you'd expect.
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.
Just make � the official symbol of the new era :)
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?
That's not a good approach to use for future events.
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.
Nice format though, other than readability. ;)
POSIX timestamps get weird around leap seconds. Time stamps get repeated, subtraction returns incorrect results, and so on.
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.
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.
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.
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)
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.
Real question
Philosophically it's a rather fun question, but practically they'll probably just honor it until the corresponding date of the new era.
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
See https://www.gov.uk/weights-measures-and-packaging-the-law
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
-ve Don't go outside
0s Wear a coat
10s Wear a jacket
20s Wear a t-shirt
30s Don't go outside
-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.
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.
a lot of construction related things that are priced by the cubic volume are still in cubic yards.
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.
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.
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 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".
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.
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.)
Is his phone number 001-0000-0001?
It is severely rude simply because it implies that said person is already dead.
" 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. "
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
The writer must be 12. The last transition, in 1989, is squarely in the middle of the information age.
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.