> > If Dave OKs this it should be a separate class. Probably DT::Undef.
>
> If Dave OKs? Does that ever happen. Unsurprisingly, I don't like this ;)
It's never happened before but I keep hoping... :)
> My experience with SQL tells me that down the path of 3-valued logic lies
> madness.
There
On Mon, 2003-07-14 at 18:19, Joshua Hoblitt wrote:
> > > If Dave OKs this it should be a separate class. Probably DT::Undef.
> >
> > If Dave OKs? Does that ever happen. Unsurprisingly, I don't like this ;)
>
> It's never happened before but I keep hoping... :)
>
> > My experience with SQL tell
On Sun, Jul 13, 2003 at 07:44:10PM -0500, Dave Rolsky 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
Ben Bennett <[EMAIL PROTECTED]> schrieb/wrote:
> As another possibility (which is what I did with my obsolete version
> of the ISO8601 parser) is to optionally take an arbitrary DT object to
> use as the base and fall back to today otherwise.
That's why a sublass of DateTime is better: This functi
Rick Measham wrote:
Except that I think, in colloquial English at least, no one refers to the year
as "twelve fifteen" except verbally.
OK, is "It was nineteen forty-seven" 1947-00-00 or 19:47:00?
The latter. As I said, the only instance of using spelled out years that I can
imagine in norma
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
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 date
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
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
> >
On Mon, 14 Jul 2003, John Siracusa wrote:
> Also, I'm slightly confused about the "responsibilities" of a
> DateTime::Format:: module. Does such a module have to have format_*
> methods, or can it get by with just parse_datetime()? I'm not sure what a
> format_* method for ::Simple should produc
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 the
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 potenti
> 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
> > Great, but the $64K question is: do we then get parse() and parser() methods
> > in DateTime, which default to use DT::F::Simple? :)
>
> Maybe. It would introduce another dependency for DateTime.pm, but OTOH
> it's a dependency that most folks would probably end up downloading
> anyway.
I'm n
Joshua Hoblitt wrote:
Not all of the format modules will deal with ambiguous cases in the same way. This sounds dangerous and error prone.
Not at all. I am not suggesting that the module magically collect all of the
possible parsing modules and just randomly call them. The default behavior
w
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() methods
in DT at all. For people who never need t
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 c
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 pars
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;"
> > 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.
>
But when you upgraded DT::LeapSecon
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 usi
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
* John Siracusa ([EMAIL PROTECTED]) [15 Jul 2003 02:59]:
[...]
> I'd gladly release the DateTime::Format::Simple I whipped
> up, but only if there is consensus about the scope of the
> module and the name ::Simple. Mine is really ::DeadSimple
> :)
My only qualm is the default American bias of the
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 cleve
On Mon, 14 Jul 2003, John Siracusa wrote:
> 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
* Ben Bennett ([EMAIL PROTECTED]) [15 Jul 2003 13:10]:
> 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.
I was going to do it, but probably wouldn't get around to
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 t
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 7/14/03 11:56 PM, Iain Truskett 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.
::Basic, maybe? Or ::Default, if we want to be boring about it.
>> Which leads to my problem, there appears to be no simple way
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
> 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.
-J
--
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
35 matches
Mail list logo
