On Mon, 14 Jul 2003, Rick Measham wrote:
Maybe an example will explain why I want to have an undef DateTime:
print $natural-parse_datetime(Feb 29th, this year)
-set( day = 31 )
-add( days = 12)
-datetime;
Of course, this won't always work because:
1. the string Feb 29th
Hi John Iain
On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
Remember: part of the point of having the various format
modules is that you can pick'n'mix. You could conceivably
wrap a number of them in Builder to make your own parser
that recognizes the sorts of dates you
On 7/14/03 12:36 PM, Hill, Ronald wrote:
Can I encourage you to put together a Format::Simple module
and release it? I think we need something out there for
very basic date parsing. There is the DateTime::Format::HTTP
that comes very close ( It works great on Ingres dates/times).
Or maybe the
On Mon, 14 Jul 2003, Hill, Ronald wrote:
On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
Remember: part of the point of having the various format
modules is that you can pick'n'mix. You could conceivably
wrap a number of them in Builder to make your own parser
that
On 7/14/03 1:05 PM, Dave Rolsky wrote:
Anything called DT::F::Simple should parse everything Date::Parse can
parse, at least, and not _too_ much more, because it should also be
reasonably fast ;)
Great, but the $64K question is: do we then get parse() and parser() methods
in DateTime, which
On Mon, 14 Jul 2003, John Siracusa wrote:
On 7/14/03 1:05 PM, Dave Rolsky wrote:
Anything called DT::F::Simple should parse everything Date::Parse can
parse, at least, and not _too_ much more, because it should also be
reasonably fast ;)
Great, but the $64K question is: do we then get
John Siracusa wrote:
Great, but the $64K question is: do we then get parse() and parser() methods
in DateTime, which default to use DT::F::Simple? :)
A while ago, when this discussion last reared its [ugly] head, I suggested that
the base class contain methods which would call an array of
Thinking about it now, it would make the most sense to me to make
DateTime::Format be an actual class which would dispatch to the DT::F::something
modules. That way, nothing needs to be added to the DateTime class itself, if
you never need parsing.
Not all of the format modules will deal
On Monday, July 14, 2003 John Peacock wrote:
John Siracusa wrote:
Great, but the $64K question is: do we then get parse() and parser() methods
in DateTime, which default to use DT::F::Simple? :)
A while ago, when this discussion last reared its [ugly] head, I suggested that
the base class
On 7/14/03 2:31 PM, John Peacock wrote:
Joshua Hoblitt wrote:
I'm not really excited about this proposed feature. If it is included the
loading of DT::F::Simple should be deferred until parse_datetime is called.
That is another reason why I suggest not having the parser() and parse()
On Mon, 14 Jul 2003, John Siracusa wrote:
That is another reason why I suggest not having the parser() and parse()
methods in DT at all. For people who never need to parse random date strings,
they only use DateTime; and they are done; everyone else does use
DateTime::Format; as well.
On Mon, 14 Jul 2003, Flavio S. Glock wrote:
On Sun, 13 Jul 2003 [EMAIL PROTECTED] wrote:
It would be easy to change the Perl code generator into a C code
generator. Then you could use DT::LeapSecond at compile time, if they
are using XS, or at runtime, if they are using pure Perl.
On 7/14/03 3:36 PM, Dave Rolsky wrote:
I'm getting concerned about DateTime bloating, not so much in terms of
code, but in terms of features. Every feature requires more docs, and
more docs means that it becomes harder and harder to figure out how to do
the one thing _you_ want DT.pm to do.
Rick Measham wrote:
Maybe an example will explain why I want to have an undef DateTime:
print $natural-parse_datetime(Feb 29th, this year)
-set( day = 31 )
-add( days = 12)
-datetime;
Yes, this makes sense to me - but I'm into functional programming.
I learned that
On 7/14/03 7:00 PM, Iain Truskett wrote:
My only qualm is the default American bias of the second regex.
Right, which is why I mentioned some sort of mode/setting. But it'd still
default to US, so there ;) Heh, maybe it'd look at your current time zone
to pick the default, or is that too
There was a recent thread out on perlmonks regarding the functionality of
DT::F::DBI:
http://www.perlmonks.org/index.pl?node_id=274054
Basically the user did not realize they were dealing with a factory and that the
API was actually documented, in their case, in DT::F::MySQL.
Perhaps a note in
On 7/14/03 11:10 PM, Ben Bennett wrote:
I am taking a whack at DT::F::Simple (please speak up now if anyone
else wants to claim this project) that can parse things that are
similar to the ones that Date::Parse can do.
Sweet, someone took the bai--...er, picked up the baton ;)
Namely:
-
On Mon, 14 Jul 2003, Ben Bennett wrote:
Which leads to my problem, there appears to be no simple way to get
the date order to differentiate m/d/y from d/m/y. I can look at the
time formats and try to work it out, but that seems a bit dodgy if you
ever change the parser, plus I assume that I
On Mon, 14 Jul 2003, Joshua Hoblitt wrote:
My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
Unfortunately, I can't think of a nice alternate for it.
I usually think of ::Simple as referring to a reduced interface. Maybe
::Basic is a better namespace.
I like ::Common,
My quibble; the name. I'm not a huge fan of ::Simple and ::Lite.
Unfortunately, I can't think of a nice alternate for it.
I usually think of ::Simple as referring to a reduced interface. Maybe
::Basic is a better namespace.
I like ::Common, since it's supposed to handle common
20 matches
Mail list logo
