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

[Clement Cervenka]

Nick,

You would surprised at the number of progammers who didn't
even know that their was this issue and even fixes.

Joe :))

--- On Mon, 8/30/10, Nick Perez <nick at nickandperla.net> wrote:

> From: Nick Perez <nick at nickandperla.net>
> Subject: Re: [DFW.pm] PHP Y2K Programming Problem!!!
> To: dfw-pm at pm.org
> Date: Monday, August 30, 2010, 1:49 PM
> 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
> _______________________________________________
> Dfw-pm mailing list
> Dfw-pm at pm.org
> http://mail.pm.org/mailman/listinfo/dfw-pm
>