<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Upcoming Y2K-like problems</title>
	<atom:link href="http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/</link>
	<description>The blog of John D. Cook</description>
	<lastBuildDate>Sat, 11 Feb 2012 01:10:06 -0500</lastBuildDate>
	<generator>http://wordpress.org/?v=2.8.4</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Marius Gedminas</title>
		<link>http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/comment-page-1/#comment-86992</link>
		<dc:creator>Marius Gedminas</dc:creator>
		<pubDate>Thu, 09 Jun 2011 09:57:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.johndcook.com/blog/?p=2487#comment-86992</guid>
		<description>Small correction: a signed 32-bit time_t will overflow in 2038 not to zero, but to approximately minus two billion seconds before the epoch, i.e. it will &quot;be&quot; December 13, 1901.

An unsigned 32-bit time_t would overflow on Feb 7, 2106, if I&#039;m not mistaken.  I don&#039;t think any systems use an unsigned time_t.</description>
		<content:encoded><![CDATA[<p>Small correction: a signed 32-bit time_t will overflow in 2038 not to zero, but to approximately minus two billion seconds before the epoch, i.e. it will &#8220;be&#8221; December 13, 1901.</p>
<p>An unsigned 32-bit time_t would overflow on Feb 7, 2106, if I&#8217;m not mistaken.  I don&#8217;t think any systems use an unsigned time_t.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jared</title>
		<link>http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/comment-page-1/#comment-19502</link>
		<dc:creator>Jared</dc:creator>
		<pubDate>Fri, 19 Jun 2009 04:06:06 +0000</pubDate>
		<guid isPermaLink="false">http://www.johndcook.com/blog/?p=2487#comment-19502</guid>
		<description>The thing about Y2K type problems is that they occur everyday with software development. Y2K bugs come with the domain of software development, where the environment around you is always changing and what was a reasonable assumption/requirement yesterday cannot apply today.

What separates a Y2K bug from a regular bug is the fact that there is an external factor (e.g. a specific date reached) and an unpredicted factor (e.g. the software would have been upgraded by that date). 

Most software is not written using architecture independent variables like size_t and time_t. If you ever see a static_cast from a `size_t` to a `UINT`, you&#039;ll be staring at a loss of data when size_t is 8 bytes and UINT stays at 4 bytes. In fact, one of the Y2K type problems that is occurring now is the move from 32-bit to 64-bit commercial software.

Consumers are purchasing 64-bit machines to replace their old 32-bit machine, and will notice a large increase in performance from software that is designed to take advantage of 64-bit machines and multiple cores. Vendors that don&#039;t make their software work well on these machines will be faced with a competitor who will.</description>
		<content:encoded><![CDATA[<p>The thing about Y2K type problems is that they occur everyday with software development. Y2K bugs come with the domain of software development, where the environment around you is always changing and what was a reasonable assumption/requirement yesterday cannot apply today.</p>
<p>What separates a Y2K bug from a regular bug is the fact that there is an external factor (e.g. a specific date reached) and an unpredicted factor (e.g. the software would have been upgraded by that date). </p>
<p>Most software is not written using architecture independent variables like size_t and time_t. If you ever see a static_cast from a `size_t` to a `UINT`, you&#8217;ll be staring at a loss of data when size_t is 8 bytes and UINT stays at 4 bytes. In fact, one of the Y2K type problems that is occurring now is the move from 32-bit to 64-bit commercial software.</p>
<p>Consumers are purchasing 64-bit machines to replace their old 32-bit machine, and will notice a large increase in performance from software that is designed to take advantage of 64-bit machines and multiple cores. Vendors that don&#8217;t make their software work well on these machines will be faced with a competitor who will.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mike Swaim</title>
		<link>http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/comment-page-1/#comment-19240</link>
		<dc:creator>Mike Swaim</dc:creator>
		<pubDate>Sun, 14 Jun 2009 23:59:26 +0000</pubDate>
		<guid isPermaLink="false">http://www.johndcook.com/blog/?p=2487#comment-19240</guid>
		<description>The Unix date problem&#039;s already hit some software. Think of 30 year mortgages. (Fortunately, in most 64 bit implementations, time_t is 64 bits. )</description>
		<content:encoded><![CDATA[<p>The Unix date problem&#8217;s already hit some software. Think of 30 year mortgages. (Fortunately, in most 64 bit implementations, time_t is 64 bits. )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wedge</title>
		<link>http://www.johndcook.com/blog/2009/06/13/upcoming-y2k-like-problems/comment-page-1/#comment-19237</link>
		<dc:creator>Wedge</dc:creator>
		<pubDate>Sun, 14 Jun 2009 23:36:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.johndcook.com/blog/?p=2487#comment-19237</guid>
		<description>Excellent post. One correction though: the &quot;twitpocalypse&quot; did not affect the twitter service itself, it only affected certain twitter apps which had been written incorrectly.

Anywho, this is a very common problem when engineers decide how much margin they need to leave and choose a figure that&#039;s low instead of high. One of the most common examples of this is insufficient lengths for name and address fields. Anyone with a first name over 10 characters long has probably seen this in action. It&#039;s almost sad how often people screw this up.

The really interesting thing about running out of IP addresses is that we&#039;ve been running out for about 10 years now, and despite massive growth in the internet we&#039;ve still, somehow, managed to come up with ever more clever efficiencies. It looks like, finally, IPv6 will become the norm, but one wonders whether it would be possible to stick with IPv4 indefinitely.

Other interesting Y2K like problems: 

ISBN numbers for books used to use only 10 digits, since 2007 new ISBNs have 13 digits (both include a check digit).

Vehicle Identification Numbers (or VINs) are running out. The existing system was only planned for a 30 year lifetime (until 2011). Even though it uses 17 digits most of the digits are used for descriptive data rather than serial number info (e.g. manufacturer, origin country, make and model, etc.)

Also, don&#039;t forget the original y2k problem! One of the more common ways of &quot;fixing&quot; the y2k problem was to introduce a sliding window such that 2 digit years less than (say) 30 translated to 20xx, whereas higher 2 digit years translated to 19xx. Some of these solutions are still in place out there, and eventually they will reach yet another rollover period and break if they aren&#039;t fixed yet again.</description>
		<content:encoded><![CDATA[<p>Excellent post. One correction though: the &#8220;twitpocalypse&#8221; did not affect the twitter service itself, it only affected certain twitter apps which had been written incorrectly.</p>
<p>Anywho, this is a very common problem when engineers decide how much margin they need to leave and choose a figure that&#8217;s low instead of high. One of the most common examples of this is insufficient lengths for name and address fields. Anyone with a first name over 10 characters long has probably seen this in action. It&#8217;s almost sad how often people screw this up.</p>
<p>The really interesting thing about running out of IP addresses is that we&#8217;ve been running out for about 10 years now, and despite massive growth in the internet we&#8217;ve still, somehow, managed to come up with ever more clever efficiencies. It looks like, finally, IPv6 will become the norm, but one wonders whether it would be possible to stick with IPv4 indefinitely.</p>
<p>Other interesting Y2K like problems: </p>
<p>ISBN numbers for books used to use only 10 digits, since 2007 new ISBNs have 13 digits (both include a check digit).</p>
<p>Vehicle Identification Numbers (or VINs) are running out. The existing system was only planned for a 30 year lifetime (until 2011). Even though it uses 17 digits most of the digits are used for descriptive data rather than serial number info (e.g. manufacturer, origin country, make and model, etc.)</p>
<p>Also, don&#8217;t forget the original y2k problem! One of the more common ways of &#8220;fixing&#8221; the y2k problem was to introduce a sliding window such that 2 digit years less than (say) 30 translated to 20xx, whereas higher 2 digit years translated to 19xx. Some of these solutions are still in place out there, and eventually they will reach yet another rollover period and break if they aren&#8217;t fixed yet again.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.734 seconds -->

