From jswitzer at gmail.com  Fri Aug 13 19:14:59 2010
From: jswitzer at gmail.com (Jason Switzer)
Date: Fri, 13 Aug 2010 21:14:59 -0500
Subject: [DFW.pm] DFW.pm reorganization
In-Reply-To: <20100812104921.1430c0af@nicklaptop.localnet>
References: <99111078AC6618449C7B28692C400D6802A3DFB8@EFJDFWMX01.EFJDFW.local>
	<99111078AC6618449C7B28692C400D6802A3E082@EFJDFWMX01.EFJDFW.local>
	<20100808182630.GC1753@pmichaud.com>
	<20100809064932.62f60d7e@netbook> <4C604D7D.90400@thecommune.net>
	<20100809170517.GA24689@pongonova.net>
	<20100809141448.2f754cc2@nicklaptop.localnet>
	<20100809195451.GB17276@pmichaud.com>
	<C4D91775-106F-4707-8459-15F9444FCECB@pobox.com>
	<20100812104921.1430c0af@nicklaptop.localnet>
Message-ID: <AANLkTik=aObvZh3ee9ogW_qyYwgKXLqxo_P7sQcDShoo@mail.gmail.com>

On Thu, Aug 12, 2010 at 10:49 AM,  <nperez at cpan.org> wrote:
> After thinking this over and talking further with Graham about this
> idea, I think it is a fantastic idea. DFW as a metroplex is /huge/.
> And it is somewhat unreasonable to expect people to always make the
> trek (that can be an hour or more depending on traffic). The group
> meeting up in Allen is an excellent success of local hackers and I
> think we could do similar things in other locales. For me personally,
> I'd love to cover the Arlington/Irving/etc central metroplex area and
> will be attempting to organize this direction. If we decide to have a
> larger event that should be inclusive of the smaller groups, we can
> make arrangements then.

I started to write a long winded email about why we called it
Dallas.p6m but it seems Graham was on target. I also am a huge fan of
DFW.pm being a representative group for the larger area; this
metroplex is big enough to host 10 groups and still grow. I don't mind
alternating the location some, and this has been discussed before, but
there isn't a vocal group of people wanting to meet elsewhere. Now
that Nick is back onboard, I would not be opposed to having a meeting
in Addison. Mainly, I'd like to see people from the area express
interest before we make rotation mandatory (otherwise, 95% of the
group will drive a long ways, which is disproportionate). Generally
though, I'm completely in favor of the idea of an umbrella org that
we're all a part of and there are "sub-chapters" that meet in
different locations.

Also, if we were to do a meeting somewhere like Addison, bi-monthly
meetings would be a good idea. In fact, these could start out as less
technical oriented and more social in nature. For example, we could
meet at Flying Saucer for beers, and then two weeks later meet for
coffee and tech chatter.

> Other notes: I sent off the email yesterday morning to get the ball
> rolling on pm.org resources (web and mailing list). I know I talked to
> a couple of guys last night that were interested in the site redesign.
> So I've started a github repo (http://github.com/nperez/dfw.pm) with a
> skeleton of how I think things should work along with a README
> explaining everything.

This is great, thanks for taking the initiative. I'll clone this and
maybe help out, but I'm not any good with webby stuff.

> Once I hear back from the pm.org people I'll alert the lists and let
> people know where to go to subscribe, and how to get your own bitcard
> account for doing things like getting WebDAV access. In the end, I want
> more people than just me able to update the website or administer the
> mailing list.

I'm in favor of the github pages; lowest barrier to entry and easiest
hosting option. I'm not opposed to committing the generated pages,
that just seems like a necessary evil (technically uploading via
webdav seems similar).

Also, I received an email about the resurrected DFW.pm mailing list;
I'm cc-ing, so I assume we want to use that as our primary mailing
list now.

-Jason

From cjcervenka at yahoo.com  Mon Aug 30 11:45:05 2010
From: cjcervenka at yahoo.com (Clement Cervenka)
Date: Mon, 30 Aug 2010 11:45:05 -0700 (PDT)
Subject: [DFW.pm] PHP Y2K Programming Problem!!!
Message-ID: <19723.58987.qm@web36806.mail.mud.yahoo.com>


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.



      

From nick at nickandperla.net  Mon Aug 30 11:49:09 2010
From: nick at nickandperla.net (Nick Perez)
Date: Mon, 30 Aug 2010 13:49:09 -0500
Subject: [DFW.pm] PHP Y2K Programming Problem!!!
In-Reply-To: <19723.58987.qm@web36806.mail.mud.yahoo.com>
References: <19723.58987.qm@web36806.mail.mud.yahoo.com>
Message-ID: <20100830134909.58dfbf9a@nicklaptop.localnet>

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