I just got back from Perl Whirl. Having spent most of the last week plugging DT as a
replacement for many of the examples given in the talks, I think we need a converting
to DT section in the FAQ or a separate document dedicated to this.
For example (I saw this in many presentations ):
use
On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
> I just got back from Perl Whirl. Having spent most of the last week
> plugging DT as a replacement for many of the examples given in the
> talks, I think we need a converting to DT section in the FAQ or a
> separate document dedicated to t
> On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
>> use POSIX qw( strftime );
>>
>> my $time = strftime( "%Y-%m-%d %H:%M:%S", localtime() );
On 10/6/03 9:16 AM, Dave Rolsky at [EMAIL PROTECTED] spake thus:
> Of course, if this is _all_ you'll ever need, c
On Mon, Jun 09, 2003 at 06:16:23PM -0500, Dave Rolsky wrote:
> On Mon, 9 Jun 2003, Joshua Hoblitt wrote:
>
> > I just got back from Perl Whirl. Having spent most of the last week
> > plugging DT as a replacement for many of the examples given in the
> > talks, I think we
On Mon, Jun 09, 2003 at 03:32:39PM -1000, Joshua Hoblitt wrote:
> > But never-the-less the website could really do with a 'Migration' section.
> > I'll volunteer to do the initial write and everyone can have CVS access to
> > keep it up-to-date.
>
> Sounds good - I was hoping someone else would vo
Unless anyone else is already doing a conversions document (or has
their heart set on doing it) I am willing to take a whack at it.
Modules to discuss conversions from:
- Date::Calc
- Date::Manip
- POSIX (and built-in Perl stuff e.g. Time::Local)
- TimeDate
- Time::Piece
Suggestions for
Unless anyone else is already doing a conversions document (or has
their heart set on doing it) I am willing to take a whack at it.
I've started on it (if you're talking about the migration document
mentioned earlier in this thread). I'd love if you want to take a
bite on one (or more) of the mod
A lot of the existing examples in the FAQ are from Date::Calc.
I can certainly take a whack at another module... where are you doing
this work? Is it part of the FAQ stuff or is it separate?
Before I leap in I would like to take a look at what you have so that
I can try to match the style.
I st
> FAQ answers should answer more questions then they generate,
> but two obvious questions leap out of that code...
>
> 1. Why is set_time_zone() needed for this DateTime example?
Good point - that should be added to the description.
> 2. Why use DateTime::Format::*MySQL* when the code may have n
Ah.
I am working on that. I decided to use Parse::RecDescent as a base.
I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
complete?) and I have it parsing simple dates and times...
Next on my list is making it understand all of the weird and wonderful
things that Date::Manip can do
> I am working on that. I decided to use Parse::RecDescent as a base.
> I have a working ISO8601 (is http://www.w3.org/TR/NOTE-datetime
> complete?) and I have it parsing simple dates and times...
That document isn't anywhere close to what is defined by ISO 8601:2000.
http://www.pvv.ntnu.no/~nsa
On Tue, 10 Jun 2003, Ben Bennett wrote:
> However, I have no idea how fast this is and how much memory it
> consumes. I will try to release what I have tonight (when I hope to
> have it in a more usable state).
I played with P::RecDescent for Mason, and it is slow and a memory hog.
That's no dis
> I played with P::RecDescent for Mason, and it is slow and a memory hog.
> That's no dis to Damian, cause it's a great tool, but in most cases a
> custom regex-based parser is way faster.
I talked to Damian about it at Perl Whirl and he said he's got plans for a major
rewrite. Although we all k
On Tue, 10 Jun 2003, Joshua Hoblitt wrote:
> > I played with P::RecDescent for Mason, and it is slow and a memory hog.
> > That's no dis to Damian, cause it's a great tool, but in most cases a
> > custom regex-based parser is way faster.
>
> I talked to Damian about it at Perl Whirl and he said he
That's too bad.
Anway, I am going to keep playing with this for a bit until I get all
of the functionality I want, then I can convert it to a re-based
thing.
-ben
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Ben Bennett wrote:
>
> > However
On Tue, Jun 10, 2003 at 03:30:05PM -0500, Dave Rolsky wrote:
> On Tue, 10 Jun 2003, Ben Bennett wrote:
>
> > However, I have no idea how fast this is and how much memory it
> > consumes. I will try to release what I have tonight (when I hope to
> > have it in a more usable state).
>
> I played w
On Wed, 11 Jun 2003, Tim Bunce wrote:
> And I'll repeat my (carefully worded) statement that "A single
> regex could handle all formats that follow the ISO 8601 general
> left-to-right decreasing resolution style, with assorted optional
> punctuation, plus optional appended TZ."
In fact, this'd b
On Wed, 11 Jun 2003, Ben Bennett wrote:
> I will do that. I didn't realize that it was so useful (too many damn
> /date|time*/i modules).
>
> I haven't looked inside yet, but this might be a good base for a more
> generic parser (Date::Manip is pretty gross).
Date::Manip's code is less than opti
On Wed, 11 Jun 2003, Tim Bunce wrote:
> > > And I'll repeat my (carefully worded) statement that "A single
> > > regex could handle all formats that follow the ISO 8601 general
> > > left-to-right decreasing resolution style, with assorted optional
> > > punctuation, plus optional appended TZ."
>
At 4:28 PM -0500 11/6/03, Dave Rolsky wrote:
5.00503 is the goal for all DateTime modules, and anyone writing a DT
module should have a damn good reason for _not_ supporting it. qr// does
indeed work with 5.00503.
Since when?
"This is perl, version 5.005_03 built for i386-freebsd"
I went throu
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 4:28 PM -0500 11/6/03, Dave Rolsky wrote:
> >5.00503 is the goal for all DateTime modules, and anyone writing a DT
> >module should have a damn good reason for _not_ supporting it. qr// does
> >indeed work with 5.00503.
>
>
> Since when?
>
> "This is
On Thu, 12 Jun 2003, Rick Measham wrote:
Does anyone have a legacy system they can try to install on?
At 4:59 PM -0500 11/6/03, Dave Rolsky wrote:
Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503,
5.6.1, and 5.8.0 before each release.
It wan't a qr//, it might have been a 'o
On Thu, 12 Jun 2003, Rick Measham wrote:
> At 4:59 PM -0500 11/6/03, Dave Rolsky wrote:
> >Yeah, me. DT.pm uses qr// internally and I always run tests on 5.00503,
> >5.6.1, and 5.8.0 before each release.
>
> It wan't a qr//, it might have been a 'our', but I don't think so,
> there was just some
I knew I had seen the assertion that qr started in 5.6.0 somewhere
recently and finally found it:
"Perl 5.6.0 introduced the ability to package up regular expressions
into variables using the qr// operator."
[From Simon Cozen's article on regexps
http://www.perl.com/pub/a/2003/06/06/regex
Ben Bennett wrote:
> Does anyone know of a quick reference to show what new syntax was
> introduced with a given release?
http://www.perldoc.com/perl5.005_03/pod/perldelta.html#New-qr---operator
Ben Bennett:
> I knew I had seen the assertion that qr started in 5.6.0 somewhere
> recently and finally found it:
> "Perl 5.6.0 introduced the ability to package up regular expressions
>into variables using the qr// operator."
> [From Simon Cozen's article on regexps
>http://www.perl.c
26 matches
Mail list logo
