[DFW.pm] PHP Y2K Programming Problem!!!

Nick Perez 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.
http://use.perl.org/articles/08/02/07/197204.shtml


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 :)))
> 
> Joe
> 
> 
> Is Your PHP Application Affected by the Y2K38 Bug? 
> 
> Right now, try running the following PHP code on your system: 
> 
> <?php
> $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
> system. 
> 
> 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):
> 
> <?php
> $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
> project.
> 
> 
> 
>       
> _______________________________________________
> Dfw-pm mailing list
> Dfw-pm at pm.org
> http://mail.pm.org/mailman/listinfo/dfw-pm
> 


-- 

Nicholas Perez
XMPP/Email: nick at nickandperla.net
http://search.cpan.org/~nperez/
http://github.com/nperez


More information about the Dfw-pm mailing list