<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Sat, 25 May 2013 12:20:51 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[XPertDeveloper.com: Is Your PHP Application Affected by the Y2K38?]]></title>
      <guid>http://www.phpdeveloper.org/news/16341</guid>
      <link>http://www.phpdeveloper.org/news/16341</link>
      <description><![CDATA[<p>
On the XpertDeveloper.com site there's a post reminding you of an date could cause all sorts of problems with your PHP application - <a href="http://www.xpertdeveloper.com/2010/08/is-your-php-application-affected-by-the-y2k38/">the effects of the Y2K38 bug</a>.
</p>
<blockquote>
<a href="http://en.wikipedia.org/wiki/Year_2038_problem">Y2K38</a>, or the Unix Millennium Bug, affects PHP and many other languages and systems which use a signed 32-bit integer to signify dates as the number of seconds since 00:00:00 UTC on 1 January 1970. The furthest date which can be stored is 03:14:07 UTC on 19 January 2038. Beyond that, the left-most bit is set and the integer becomes a negative decimal number or a time prior to the epoch.
</blockquote>
<p>
If you're worried about your application's support for date and time handling, there's a pretty simple fix - replace your current handling with the <a href="http://php.net/datetime">DateTime</a> functionality. This handles them correctly.
</p>]]></description>
      <pubDate>Mon, 16 May 2011 09:22:18 -0500</pubDate>
    </item>
    <item>
      <title><![CDATA[SitePoint PHP Blog: Is Your PHP Application Affected by the Y2K38 Bug?]]></title>
      <guid>http://www.phpdeveloper.org/news/15009</guid>
      <link>http://www.phpdeveloper.org/news/15009</link>
      <description><![CDATA[<p>
On the SitePoint PHP blog today they pose a question to all PHP developers out there - is your application <a href="http://www.sitepoint.com/blogs/2010/08/24/is-your-php-application-affected-by-the-y2k38-bug/">affected by the Y2K38 bug</a>?
</p>
<blockquote>
I don't want to be too alarmist, but try running the [given] PHP code on your system. [...] With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in your browser. If you're seeing a date in the late 60's or early 70's, your PHP application may be at risk from the Y2K38 bug!
</blockquote>
<p>
The bug, caused by a 32-bit operating system, can be helped by running the application on a 64-bit platform (it's due to the limitation of integer size), but there is another option - the <a href="http://www.php.net/manual/en/class.datetime.php">DateTime</a> class that handles dates and times differently than the just using the local time settings.
</p>]]></description>
      <pubDate>Tue, 24 Aug 2010 10:12:23 -0500</pubDate>
    </item>
  </channel>
</rss>
