为什么日本改元“令和”，竟然成了程序员的魔咒？
来源 | PingWest品玩（ID：wepingwest） 作者 | 邢逸帆 从5月1日开始，日本彻底告别了平成时代，步入令和元年。 而且由于天皇更替举国欢庆，日本往年最长只有 5 天的黄金周将被加量到 10 天，也就是说，日本社畜即将迎来梦幻般的十连休！
这也是自1948年日本颁布《假日法》以来的首个十连休
但对于已经到来的令和元年十连休，也不是每个人都欢天喜地。因为伴随着新元号而来的，是一系列烦死人的系统年号变更问题。
作为全球唯一保留了年号和皇历的国家，尽管日本在日常生活中也普遍使用公历，但无论是银行、证券、保险等金融机构还是行政机关，都仍在使用年号纪元。
东京证券交易所
因此，从2019年5月1日正式改元开始，日本所有的电脑和软件系统都必须在当天同步改用新年号。而在日的国际 IT 公司，更需要将公历与日本皇历切换，将日本使用的软件版本日期更新为新年号纪元。
而且，1989 年开启的长达 30 的年平成时代里，互联网信息技术迅猛发展，比起上次改元时，今日的网络系统对人们生活的影响已不可同日而语。如今电脑、手机、保险券甚至 ATM 机都已经接入了计算机系统，对于日本程序员来说，让所有的计算机都在5月1日同步改元，这还是历史上从未有过的大挑战……
以至于一位 Twitter 网友吐槽到：在改元的祝贺气氛里，IT 从业者看到这幅画面却只想骂人。
身为 IT 业不相关人士、隔壁看戏人员，大家可能无法理解日本程序员“随时都会被拖出去祭天”的恐慌，然而在程序员甚至日本政府看来，改元确实是件关系国计民生的大事。
令和开年有点慌尽管从小接受西式教育、业余热衷研究虾虎鱼的明仁天皇非常特立独行，2016 年就宣布自己将打破惯例成为第一位生前退位的天皇，然而新年号还是要等到退位前一个月才能揭晓。对于需要做出“技术性调整”的各行业人员来说，真正留给他们的时间只有短短一个月。
于是，新年号甫一公布，全日本上下立刻紧张了起来！
一些选择手动升级的中小企业为了继续利用已经打印出的文件，开始抢刻令和年号橡皮章，橡皮章一时洛阳纸贵。
办公用品制造商 Hanko21 的总经理泷口修表示，自己从4月1日起就开始亲自下场和 20 多名工人加班加点在工厂里赶制令和图章，但是他的努力没有维持多久，因为“年号公布三天后，我们囤积的橡胶原料就全部用完了。”
而为了在一个月内对旗下的八十多个行政单位计算机系统进行快速调整，名古屋市政府拨款四亿八千万日元进行加班加点在5月1日前完成了赋税、社会保障等重要系统的改造，但还有更多“不紧迫”的系统会留在1至7日由程序员加班完成……
当然，最发愁的还是电脑系统老旧过时的私人小企业。因为更新系统耗资巨大，有些日本公司的电脑系统已经二三十年没有更新过了，几乎和平成年代一样古老，根本无法自动升级。
面对改元，山梨县北杜市的一家老字号点心铺可能是少有的能淡然处之的实体之一。这家店的老板在30多年前昭和时代预定账本时，把 50 本订成了 5000 本，整个平成时代过去了账本还没用完。
元号变成令和后，起码老板今后只用改一个字了（昭和改令和）。
中小公司改元乱成一锅粥，而那些自称“我好了！”的公司，也纷纷出现大漏洞。
一个月前微软表示，将通过云端向日本客户推送令和更新包。而5月1日上午，就有还在加班的日本上班族表示 Excel 日期混乱，不仅显示出平成31年5月1日这种不存在的日期，公历年份还变成了 5 位数。
与此同时，北海道银行、北陆银行和横滨银行开始发生大面积 ATM 机混乱事故。所有转账日期都变成了1989年5月7日，至于被转走的钱到底去了哪里利息怎么计算谁也不知道（毕竟在系统里这已经是一笔来自1989年，存了 30 年的钱），不过这三家银行表示他们有信心尽快修复错误。
而这场旷日持久的改元混乱，还要持续到5月7日。
在2019年5月1日内阁会议后的新闻发布会上，日本内阁官房长官菅义伟宣布，尽管5月1日年号就已经更替为令和，但改元工作要到5月7日才会结束。“我们不会影响公众生活。”菅义伟说，但日本民众对此存疑。
何事惊慌？也许有人不理解，“年号不过是一个名字而已，会造成这么大的影响吗？”
事实是，年号与日本的计算机系统和各种证件的计数系统息息相关，一旦出现混乱，轻则证件失效，重则金融交通系统崩溃。
比如著名的“驾照迷思”。平成29年发放的驾照有效期至平成32年（2020年），然而在这个日期来临前日本就已经进入了令和时期，理论上平成32年是不存在的。
人工操作时还比较好加以判断，然而对于六亲不认的计算机来说，所有有效期在平成31年4月30日以后的契约合同证件证券，全部都是无效的。
此时，就需要程序员们上阵迅速修改系统，保证人们的正常生活了。
而在平成12年（即2000年）2月，因为日本程序员忽略了2000年是个大闰年，没有在系统里加入29日，这一天在北海道札幌市拿月票卡通勤的上班族统统被堵死在路上，造成了交通瘫痪和大面积迟到。
虽然犯这种低级错误的真实原因已经不得而知，但总觉得换做用公元纪年的话，应该挺好发现2000年是闰年的。
因为年号和计算机系统实在过于烦人，维基百科专门在日语“元号”条目中加入了“元号与计算机”这一栏，长篇大论元号的种种弊端。
日本程序员受的苦，外人真的没法数。
令和之后会更慌尽管令和的劫已经快渡完了，但日本程序员的夜明还远远没有来到……
在2019年开年之初，有一位程序员小姐姐在 Twitter 上提醒大家：“比起新元号对应问题，还有更需要担心的事哦～昭和 100 年就快要到了哦～”
她的言论立刻引发大量转发，评论区一片程序员的悲鸣。
日本的昭和时代从1926年开始，1989年结束，历经 64 年，因此昭和年号最多只有 64 年。那么让日本程序员听了就要跪的昭和 100 年又是什么鬼？
这还要归功于前代程序员绵延三十年甩来的巨锅。
1989年，日本经历了昭和到平成的改元，那时的电脑还比较原始，内存只有 64-128KB，每一个 bit 都至关重要，程序员只能想方设法从各种地方抠内存。于是，在记录日期时，年份都只会记录后两位，比如1989年1月1日，就会被记录为 890101。
然而一旦到了2000年，巨大的 bug 就出现了。由于只保留后两位数，银行里面的电脑可能把2000年解释为1900年，从而算错利息甚至直接消除账面记录，而你在1999年12月31日23：59分打了三分钟的电话，电话局的账单却可能出现负数计数而导致系统崩溃（-100年+3分钟）。
这就是大名鼎鼎的千年虫问题。
在全球同行都为千年虫焦虑不已的同时，先代日本程序员们却灵机一动……
如果继续延用昭和年号计数的话，千年虫问题就会被推后 25 年，即昭和 100 年（ 2025 年）才归零！比别人多了 25 年，肯定足够我们解决问题了！
所以如今日本政府和企业的系统里表面上看起来一团和气，实则一直在底层为昭和续命。
然而眼看令和元年都来了，清算的日期还有六年就要到了，新一代日本程序员们面对 COBOL 等上古语言开发的系统却更加迷惑了。
“银行和大企业的基础系统像古董一样脆，怎么也不能更新……！”
“30年40年前的代码根本没有说明文档，剩下的部分也没有追加变更记录！”
“法律规定的5年追诉期早就过了，因为人事变动，当年的负责人全都找不到了。”
日本程序员大型崩溃，只能祈祷到 2025 年自己已经转行了……
当然看热闹不嫌事大的人也是存在的。
“从平成到令和时代，昭和100年问题即将到来，好像被遗忘的时代的亡灵要来了，这不是很帅吗？”
到那时面对“时代的亡灵”，日本程序员会不会想出新的甩锅办法，那就是另一个故事了。
至于当年甩锅的老程序员则表示，“谁能想到 20 年后你们还在用这一套啊！！”
果壳ID：Guokr42
也许有人不理解，“年号不过是一个名字而已，会造成这么大的影响吗？”
事实是，年号与日本的计算机系统和各种证件的计数系统息息相关，一旦出现混乱，轻则证件失效，重则金融交通系统崩溃。
比如著名的“驾照迷思”。平成29年发放的驾照有效期至平成32年（2020年），然而在这个日期来临前日本就已经进入了令和时期，理论上平成32年是不存在的。
人工操作时还比较好加以判断，然而对于六亲不认的计算机来说，所有有效期在平成31年4月30日以后的契约合同证件证券，全部都是无效的。
此时，就需要程序员们上阵迅速修改系统，保证人们的正常生活了。
而在平成12年（即2000年）2月，因为日本程序员忽略了2000年是个大闰年，没有在系统里加入29日，这一天在北海道札幌市拿月票卡通勤的上班族统统被堵死在路上，造成了交通瘫痪和大面积迟到。
虽然犯这种低级错误的真实原因已经不得而知，但总觉得换做用公元纪年的话，应该挺好发现2000年是闰年的。
因为年号和计算机系统实在过于烦人，维基百科专门在日语“元号”条目中加入了“元号与计算机”这一栏，长篇大论元号的种种弊端。
日本程序员受的苦，外人真的没法数。
令和之后会更慌尽管令和的劫已经快渡完了，但日本程序员的夜明还远远没有来到……
在2019年开年之初，有一位程序员小姐姐在 Twitter 上提醒大家：“比起新元号对应问题，还有更需要担心的事哦～昭和 100 年就快要到了哦～”
她的言论立刻引发大量转发，评论区一片程序员的悲鸣。
日本的昭和时代从1926年开始，1989年结束，历经 64 年，因此昭和年号最多只有 64 年。那么让日本程序员听了就要跪的昭和 100 年又是什么鬼？
这还要归功于前代程序员绵延三十年甩来的巨锅。
1989年，日本经历了昭和到平成的改元，那时的电脑还比较原始，内存只有 64-128KB，每一个 bit 都至关重要，程序员只能想方设法从各种地方抠内存。于是，在记录日期时，年份都只会记录后两位，比如1989年1月1日，就会被记录为 890101。
然而一旦到了2000年，巨大的 bug 就出现了。由于只保留后两位数，银行里面的电脑可能把2000年解释为1900年，从而算错利息甚至直接消除账面记录，而你在1999年12月31日23：59分打了三分钟的电话，电话局的账单却可能出现负数计数而导致系统崩溃（-100年+3分钟）。
这就是大名鼎鼎的千年虫问题。
在全球同行都为千年虫焦虑不已的同时，先代日本程序员们却灵机一动……
如果继续延用昭和年号计数的话，千年虫问题就会被推后 25 年，即昭和 100 年（ 2025 年）才归零！比别人多了 25 年，肯定足够我们解决问题了！
所以如今日本政府和企业的系统里表面上看起来一团和气，实则一直在底层为昭和续命。
然而眼看令和元年都来了，清算的日期还有六年就要到了，新一代日本程序员们面对 COBOL 等上古语言开发的系统却更加迷惑了。
“银行和大企业的基础系统像古董一样脆，怎么也不能更新……！”
“30年40年前的代码根本没有说明文档，剩下的部分也没有追加变更记录！”
“法律规定的5年追诉期早就过了，因为人事变动，当年的负责人全都找不到了。”
日本程序员大型崩溃，只能祈祷到 2025 年自己已经转行了……
当然看热闹不嫌事大的人也是存在的。
“从平成到令和时代，昭和100年问题即将到来，好像被遗忘的时代的亡灵要来了，这不是很帅吗？”
到那时面对“时代的亡灵”，日本程序员会不会想出新的甩锅办法，那就是另一个故事了。
至于当年甩锅的老程序员则表示，“谁能想到 20 年后你们还在用这一套啊！！”果壳ID：Guokr42
果壳 ID：Guokr42
