The FreeBSD Project actually had a gigasecond bug -- the cvsup protocol (used for CVS tree replication and checkouts) transmitted time as an ASCII seconds-since-epoch value, and when September 2001 arrived, the changed string length caused a protocol sanity check to fail.

Yes. In java at the time if you wrote a number with 9 or less digits, it would always be considered to be an int. If the number was above 1 billion (10 digits), you had to end it with an L (1000000000L), probably since it possibly could overflow an int.

We had a trial version of our software that would expire after 30 days. To make that we had a script that inserted the expiry date into the source and recompiled every night. Around 30 days before it passed 1 billion the compiler started to give an error, and the script crashed.

(It may actually have been 12->13 digits, since java use milliseconds since the epoch, but I'm not so sure this many years later)

Yes, this was on the radar then as Y2k was still fresh in everyone's memory.

[1] "S1B coming" http://tech.slashdot.org/story/01/04/17/1915221/the-quickly-...

[2] "Any Billennium Bugs?" http://tech.slashdot.org/story/01/09/10/0353238/billenniums-...

Yes, I remember it fondly, celebrating the 'billennium' on IRC:

https://krux.org/misc/billennium_log

Openldap got hit by the billennium bug. I remember because we told our Noc to keep an eye open (Sunday afternoon where we were) and we started getting alerts that all LDAP replication was broken.

http://www.openldap.org/lists/openldap-bugs/200109/msg00052....

Yes.. I ran a small service started in 2000 that saved epoch times in a varchar column. Sorting on time turned funky for a short while.

Or perhaps Fri, 13 Jul 2012 11:01:20 GMT, unix time 0x50000000? Developers using MongoDB at the time were likely to notice.

apparently: http://blog.jdlh.com/en/2009/02/12/1234567890_day/1000000000...