Hacker News Reader

Comment by rhdunn | Hacker News Reader

The Y2K problem would have manifested as the year 2000 being interpreted as 1900. As such, it could have affected anything around dates (age verification, paynment due dates, morgages, etc.). Other more extream issues (power outages) would have been unlikely but it is impossible to predict all the knock-on effects Y2K would have had.

There were several issues that happened as a result of Y2K.

View on HN

Maybe you are being downvoted because this is “obvious”, but as it turns out it is not obvious enough for the TFA itself to not have this error:

    it prophesied that on January 1, 2000, computers the world over would be unable to process the thousandth-digit change from 19 to 20 as 1999 rolled into 2000 and would crash

I came across a reasonable amount of perl code that happily formatted the year 2000 as 19100. The functions that converted from seconds-since-1970 to a "human readable" parts returned a year relative to 1900. Most people would format using sprintf("%d/%d/%d",$d,$m+1,$y+1900) but some code I inherited instead used sprintf("%d/%d/19%d",$d,$m+1,$y). I never did figure out if it was due to stupidity or malice.

I kept seeing this behaviour on some websites in to the late 00s and possibly even in to the early 10s, your comment mede me realise I haven't seen it recently though :(

A big part of that problem was Javascript's terrible Date API, which was practically a carbon copy of the (equally terrible) java.util.Date. For no good reason, its Date.getYear() method returned the number of years since 1900.

I remember booting up an emulated CADR for the first time and, after entering the date as something, something, 2008, was startled for the status bar to read a year of 19108.

I also did my quick Lisp sanity test of saying (* 4 3) and expecting 12 -- but I got 14 instead. It was then that I learned the CADR speaks octal by default.

Reply on news.ycombinator.com