8 ms·

How pervasive is the Japanese calendar in computing actually? I suppose most programs calculate all dates internally using UNIX timestamps or UTC and only conve

by yoz-y 8y ago

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?

holtalanm 8y ago
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.
- mipmap04 8y ago
  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.
- yoz-y 8y ago
  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.
- PeterisP 8y ago
  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.
jerf 8y ago
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.
- ajuc 8y ago
  > tax forms that have � in the date Just make � the official symbol of the new era :)
- bsder 8y ago
  > 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?
- oftenwrong 8y ago
  >"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.
SmellyGeekBoy 8y ago
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.
- fishtank 8y ago
  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.
- innocenat 8y ago
  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.
  - jrockway 8y ago
    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.)
  - mercurysmessage 8y ago
    Alien card? Do you mean the zairyu card?
- jcelerier 8y ago
ginko 8y ago
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/reserved_ticket.jpg 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)
- h1d 8y ago
  At least it's clear it's not 2022 in 2010 but imagine if they were close... Now we're resetting it down to 1, perhaps no big confusion but still, a pointless system.
  - illirik 8y ago
    Is history pointless?
peapicker 8y ago
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.
veidr 8y ago
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.
- pwim 8y ago
  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.
  - samatman 8y ago
    Does this imply that the driver's license becomes invalid and must be replaced with one in the new date system? Real question
    - tonysdg 8y ago
      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.
    - h1d 8y ago
      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.
Forge36 8y ago
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)
i_made_a_booboo 8y ago
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.

by yoz-y 8y ago

holtalanm 8y ago

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.

mipmap04 8y ago
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.
yoz-y 8y ago
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.
PeterisP 8y ago
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.

jerf 8y ago

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.

ajuc 8y ago
> tax forms that have � in the date Just make � the official symbol of the new era :)
bsder 8y ago
> 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?
oftenwrong 8y ago
>"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.

SmellyGeekBoy 8y ago

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.

fishtank 8y ago
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.
innocenat 8y ago
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.
- jrockway 8y ago
  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.)
- mercurysmessage 8y ago
  Alien card? Do you mean the zairyu card?
jcelerier 8y ago

ginko 8y ago

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/reserved_ticket.jpg 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)

h1d 8y ago
At least it's clear it's not 2022 in 2010 but imagine if they were close... Now we're resetting it down to 1, perhaps no big confusion but still, a pointless system.
- illirik 8y ago
  Is history pointless?

peapicker 8y ago

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.

veidr 8y ago

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.

pwim 8y ago
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.
- samatman 8y ago
  Does this imply that the driver's license becomes invalid and must be replaced with one in the new date system? Real question
  - tonysdg 8y ago
    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.
  - h1d 8y ago
    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.

Forge36 8y ago

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)

i_made_a_booboo 8y ago

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.