TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

The Y2K bug is back, causing headaches for developers again

104 点作者 nikbackm超过 5 年前

16 条评论

darrenf超过 5 年前
I worked on a 2k20 bug just last week. Some of the Perl at work started returning strange values, and tests were failing. Turns out we were using `Time::Local`&#x27;s `timelocal&#x2F;timegm` subs. They use convoluted interpretation of 2-digit years – which we were, of course, passing (and for no good reason):<p>• <a href="https:&#x2F;&#x2F;metacpan.org&#x2F;pod&#x2F;Time::Local#Year-Value-Interpretation" rel="nofollow">https:&#x2F;&#x2F;metacpan.org&#x2F;pod&#x2F;Time::Local#Year-Value-Interpretati...</a><p>&gt; <i>Years in the range 0..99 are interpreted as shorthand for years in the rolling &quot;current century,&quot; defined as 50 years on either side of the current year. Thus, today, in 1999, 0 would refer to 2000, and 45 to 2045, but 55 would refer to 1955. Twenty years from now, 55 would instead refer to 2055. This is messy, but matches the way people currently think about two digit dates</i><p>• <a href="http:&#x2F;&#x2F;blogs.perl.org&#x2F;users&#x2F;tom_wyant&#x2F;2020&#x2F;01&#x2F;my-y2020-bug.html" rel="nofollow">http:&#x2F;&#x2F;blogs.perl.org&#x2F;users&#x2F;tom_wyant&#x2F;2020&#x2F;01&#x2F;my-y2020-bug.h...</a>
评论 #22045835 未加载
JauntyHatAngle超过 5 年前
I know a mainframe dev who worked on y2k across a bunch of systems at the time.<p>Asked him about it, he said that they warned management not to window the code to 2020, and showed alternatives that would take longer to code but would be future proofed.<p>Most agreed with enough convincing. Some did not, usually with the argument of &quot;the systems won&#x27;t even be around in 2020!&quot;.
评论 #22046670 未加载
评论 #22048018 未加载
评论 #22046338 未加载
Arnavion超过 5 年前
Speaking of pivot years, there&#x27;s a similar rollover in 2050 for RFC 5280 style datetimes, eg not-before and not-after times in X.509 certificates. The RFC defines two datetime string formats - &quot;UTCTime&quot; which has a two-digit year, and &quot;GeneralizedTime&quot; which as a four-digit year. The two-digit one is parsed as 0 &lt;= YY &lt; 50 implying 20YY and 50 &lt;= YY &lt; 100 implying 19YY. For not-before and not-after times, certificates are required to use UTCTime for datetimes before 2050 and only use GeneralizedTime for times after that.<p>So there can be applications today that parse ASN.1 datetimes manually (1) but only expect the UTCTime format. They&#x27;ll break when they encounter a cert with a not-after beyond 2050 because it&#x27;ll be in the GeneralizedTime format instead.<p>Luckily this one will be detected over a period of time rather than happening at precisely 2050-01-01 00:00:00, so there&#x27;s more time to fix it in each application that has the bug.<p>(1) if the application wants to parse it into a `struct tm` for manipulation, for example. For that specific case, openssl 1.1.1 added `ASN1_TIME_to_tm`, so it&#x27;s only a problem for applications that don&#x27;t use openssl or need to support older versions. One can hope that at least the latter will stop being a requirement as 2050 gets closer.
评论 #22048108 未加载
jedberg超过 5 年前
I&#x27;m more worried about the Y2K38 problem.<p>I&#x27;ll be just over 60 years old when that happens. With any luck, I&#x27;ll be retired and not have to worry about it... I think having to deal with both Y2K and Y2K38 in one career is too much.
评论 #22048945 未加载
close04超过 5 年前
I remember disconnecting my dialup session and checking that nobody is on the phone as the clock ticked midnight just to make sure we don&#x27;t get billed for a 100 year long call.
评论 #22046089 未加载
评论 #22045310 未加载
hoiuyoi9087超过 5 年前
I think it&#x27;s hilarious some fixed the Y2K bug by introducing a Y2K20 bug. Planned obsolescence&#x2F;long con.
评论 #22047452 未加载
评论 #22045246 未加载
评论 #22045332 未加载
评论 #22046323 未加载
MockObject超过 5 年前
It&#x27;s not clear to me why anyone in 2000 would choose 20 as the pivot year, unless they were working on a system that needed to regard 1921. Why wouldn&#x27;t a parking meter or subway system pivot at, say 1990?
评论 #22049607 未加载
评论 #22049270 未加载
bhaak超过 5 年前
FWIW, at work we have regular failing tests after new year as the automated tests usually work with the current year.<p>So I can relate that it&#x27;s easy to write buggy date handling code even today.<p>But at least we have tests. All those poor programmers that worked on Y2K didn&#x27;t have them. And those that work on Y2k20 bugs probably still don&#x27;t.
评论 #22048555 未加载
ravedave5超过 5 年前
We had a build script that expected the final digit of the year to end between 4-9. Dumbest code I&#x27;ve seen in a while. Broke pretty bad on 2020.
评论 #22048208 未加载
mirekrusin超过 5 年前
Any self respecting developer had chose 42 as pivot year.
jacobr超过 5 年前
Sounds like a reasonable solution for some systems in 1999. How many of the systems that were fixed properly died the following years anyway, and the millions invested were overkill and unnecessary?<p>In some cases “kicking the ball down the road” makes perfect sense, just fixing what is most urgent.
villgax超过 5 年前
Bigger deal is with 2038 bug
评论 #22046127 未加载
评论 #22045313 未加载
评论 #22046363 未加载
评论 #22045354 未加载
chelmzy超过 5 年前
Splunk had a Y2020 bug as well
caseymarquis超过 5 年前
Representing time may be the third hard problem in computer science. The more you dig, the worse it gets.
dhosek超过 5 年前
In 1999, I was fixing Y2K bugs at a company founded in 1997.<p>At least the programmers writing code in the 80s had an excuse. It was the Reagan years. Nobody thought civilization would make it until the year 2000.
评论 #22046016 未加载
评论 #22045690 未加载
mark-r超过 5 年前
The only fail I saw from the original Y2K was a credit card receipt dated 1&#x2F;2&#x2F;100.
评论 #22048070 未加载
评论 #22047822 未加载
评论 #22047777 未加载