[DFW.pm] PHP Y2K Programming Problem!!!
nick at nickandperla.net
Mon Aug 30 11:49:09 PDT 2010
Um. Dude. You do realize that Perl has nothing to do with PHP right?
And anyhow, Schwern fixed this issue for Perl back in 2008.
On Mon, 30 Aug 2010 11:45:05 -0700 (PDT)
Clement Cervenka <cjcervenka at yahoo.com> wrote:
> Hi All,
> Just came across this PHP Y2K problem, that you all
> might want to be FYI about this :)))
> Is Your PHP Application Affected by the Y2K38 Bug?
> Right now, try running the following PHP code on your system:
> $date = '2040-02-01';
> $format = 'l d F Y H:i';
> $mydate1 = strtotime($date);
> echo '<p>', date($format, $mydate1), '</p>';
> With luck, you'll see "Wednesday 1 February 2040 00:00" displayed in
> your browser. But if you're seeing a date from the late 1960s or
> early '70s, your PHP application may be at risk from the Y2K38 bug!
> What's the Y2K38 bug?
> Y2K38, or the Unix Millennium Bug, affects PHP and many other
> languages and systems which use a signed 32-bit integer to represent
> dates as the number of seconds since 00:00:00 UTC on 1 January 1970.
> The furthest date that 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.
> Yes, the furthest date is 28 years away, and I'm sure many of you
> think it's ridiculous to worry about it now. However, developers
> thought that way about the Millennium Bug in the 1970s and '80s.
> Also, any web application that handles long-term future events could
> be at risk. For example, consider that a typical mortgage runs for 25
> years, while pensions and savings plans can be far longer. Will
> 64-bit save us?
> Probably. If you're using a 64-bit OS with a compiled 64-bit edition
> of PHP, your application shouldn't be affected. I do recommend that
> you test it, though.
> A signed 64-bit number gives a maximum future date that is 21 times
> greater than the current age of the universe: 292 billion years, give
> or take a day or two. You can probably rest easy if you're confident
> your financial application will always be installed on a 64-bit
> Are there alternative options?
> Fortunately, PHP introduced a new DateTime class in version 5.2
> (experimental support was available in 5.1, and be aware that some
> methods were introduced in 5.3):
> $date = '2040-02-01';
> $format = 'l j F Y H:i';
> $mydate2 = new DateTime($date);
> echo '<p>', $mydate2->format($format), '</p>';
> DateTime does not suffer from Y2K38 problems and will happily handle
> dates up to December 31, 9999. I hope to have paid off my mortgage by
> then! It may not be worth upgrading existing applications, but you
> should certainly consider the DateTime class when planning your next
> Dfw-pm mailing list
> Dfw-pm at pm.org
XMPP/Email: nick at nickandperla.net
More information about the Dfw-pm