<?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>Tue, 21 May 2013 21:50:37 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Pumka.net: Why MySQL timestamp is 24 seconds different from PHP]]></title>
      <guid>http://www.phpdeveloper.org/news/15336</guid>
      <link>http://www.phpdeveloper.org/news/15336</link>
      <description><![CDATA[<p>
On the Pumka.net blog, <i>Anton Oliink</i> has <a href="http://blog.pumka.net/2010/10/24/why-mysql-timestamp-is-24-seconds-different-from-php/">an interesting problem</a> where his timestamp on the PHP side of his application was different than the one on his MySQL backend's side - by 24 seconds, in fact.
</p>
<blockquote>
You may find that timestamp value returned by MySQL UNIX_TIMESTAMP() function is 24 seconds grater than those returned by PHP functions and classes like strtotime(), mktime, DateTime::getTimestamp(), Zend_Date::getTimestamp().
</blockquote>
<p>
As it turns out, the issue isn't' really an "issue" after all - it's caused by MySQL's compensation for <a href="http://en.wikipedia.org/wiki/Leap_second">leap seconds</a>. He gives a few ways you can avoid it being an issue in your application, though: disable leap seconds, only convert to timestamps on the PHP side or just use the "unix_timestamp()" and "from_unixtime()" methods to work with the values.
</p>]]></description>
      <pubDate>Tue, 26 Oct 2010 11:24:31 -0500</pubDate>
    </item>
  </channel>
</rss>
