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?
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.
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)
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.