It appears the second Twitpocalypse is due to hit around the end of September.  Why so soon?  Why at all?

Back in June, Twitter faced its first, so called, Twitpocalypse.  It was blown a bit out of proportion and described somewhat inaccurately.  The problem did not affect Twitter itself, but rather some of the third party applications written to access Twitter

A non-technical description of the problem goes something like this.  Twitter assigns a number to each tweet that is posted.  Some third party applications used a numeric data type (32-bit signed integer) that was too small to hold this constantly growing number.  As a result, when this number exceeded the capacity of third party applications, they stopped working properly.  For most of the affected programs, they appeared to work fine on the surface, but would not display new tweets.  Many of the developers addressed this issue prior to the first Twitpocalypse and the others scrambled to resolve the issue after it occurred.

Now, just over thirty days after the first Twitpocalypse, it is believed that a second occurrence will take place around the end of September.  This second event is also related to third-party applications, not Twitter itself.  The reason for the repeat is likely two-fold.  First, it is likely that some developers originally wrote their Twitter applications using a different numeric data type than described above (32-bit unsigned integer).  The unsigned data type can hold numbers roughly twice as large as its signed counterpart, but is still too small to avoid trouble in this case.  The second possible cause is that some of the developers affected by the first Twitpocalypse changed their data type from signed to unsigned which proved to be a short term solution.

Developers are being encouraged to use 64-bit integer types in their third party Twitter applications.  With the growing popularity of Twitter, could this one day become a direct problem for the social media giant?