John Siracusa schreef:
> All the various DateTime::Format::* modules are nice, but I've been
> thinking that it would be even nicer if DateTime had some sort of
> rudimentary parsing built in.
I agree with this; the DateTime constructor tends to get a little
verbose. However, I don't quite agree
On 7/13/03 6:47 AM, Eugene van der Pijll wrote:
>> 1/20/2002 1:02 p.m. (okay, maybe a Euro-mode for dd/mm/ :)
>
> A parser that can parse this format correctly should not be called
> Simple. As you say, it has to have a US and a Euro mode at least; the
> default DateTime parser should be s
John Siracusa schreef:
> On 7/13/03 6:47 AM, Eugene van der Pijll wrote:
> > A parser that can parse this format correctly should not be called
> > Simple. As you say, it has to have a US and a Euro mode at least; the
> > default DateTime parser should be simple enough to need no
> > configuration.
John Siracusa schreef:
> All the various DateTime::Format::* modules are nice, but I've been
> thinking that it would be even nicer if DateTime had some sort of
> rudimentary parsing built in.
On Sun, 2003-07-13 at 20:47, Eugene van der Pijll wrote:
> I agree with this; the DateTime constructor
* John Siracusa ([EMAIL PROTECTED]) [14 Jul 2003 01:53]:
[...]
> See above. It's like 4 or 5 regexes for
> DateTime::Format::Simple. I know, because I have a
> DateTime wrapper that parses these formats, it it covers
> about *99.9%* of the date strings I encounter, including
> user input in web fo
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 recognises the sorts of dates you come across. I mostly
come a
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 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
* 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
* Bruce Van Allen ([EMAIL PROTECTED]) [15 Jul 2003 04:55]:
[...]
> 6. All parsers fail (return undef) if they can't parse a
>string, both for good programming practice and to allow
>falling through to the next specified/available parser
>module;
I'm yet to see a consistent method of h
On Wed, 16 Jul 2003, Iain Truskett wrote:
> What do people think parsers should return if they can't
> parse? And what if they do parse, but DateTime doesn't want
> to create an object of the appropriate specification?
>
> Should we wrap our methods in evals and return undef?
>
> Should we just th
At 3:42 PM +1000 16/7/03, Iain Truskett wrote:
What do people think parsers should return if they can't
parse? And what if they do parse, but DateTime doesn't want
to create an object of the appropriate specification?
DateTime::Undef :)
If all modules return DateTime::Undef and all modules handle
On Wed, 16 Jul 2003, Rick Measham wrote:
> At 3:42 PM +1000 16/7/03, Iain Truskett wrote:
> >What do people think parsers should return if they can't
> >parse? And what if they do parse, but DateTime doesn't want
> >to create an object of the appropriate specification?
>
> DateTime::Undef :)
>
> I
* Dave Rolsky ([EMAIL PROTECTED]) [16 Jul 2003 16:11]:
[...]
> Fatal errors are a _good_ thing. Forging ahead with bad
> data and _not_ getting errors is a very, very, very bad
> thing.
autarch++
Despite most of the _innards_ of Builder returning undef
when they hit problems, all the external me
On Wed, 16 Jul 2003, Iain Truskett wrote:
What do people think parsers should return if they can't
parse? And what if they do parse, but DateTime doesn't want
to create an object of the appropriate specification?
Should we wrap our methods in evals and return undef?
Should we just throw error
Rick Measham <[EMAIL PROTECTED]> schrieb/wrote:
> DateTime::Undef :)
> If all modules return DateTime::Undef and all modules handle it when
> passed it, then everything flows.
> If we return undef, then we need to make sure all methods can handle
> undef parameters cleanly. Of course, we really ca
John Siracusa <[EMAIL PROTECTED]> schrieb/wrote:
> 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 clever by half? :)
I don't like the idea that a programme
Dave Rolsky <[EMAIL PROTECTED]> schrieb/wrote:
> Fatal errors are a _good_ thing. Forging ahead with bad data and _not_
> getting errors is a very, very, very bad thing.
DBI has an option RaiseError. We could:
. have a variable $DateTime::AutoRaise (which should be overridden using
local)
. ha
> Actually, DT::Undef is just a special case of the proposed DT::Partial
> object.
Not really - it's totally different state. Any partial time can already be expressed
with the current DT class. We just need a means to specify the precision.
-J
--
Rick Measham <[EMAIL PROTECTED]> schrieb/wrote:
>> Right, they won't bother using the eval (at first) and so will be forced
>> to deal with data problems. Why is that bad?
> Same with not using $dt->is_undef.
At least the programme fails and prints an error message instead of
silently using wr
Here's my take on handling parse errors, and error handling in general.
1. I don't like to (unconditionally) die from within libraries except for
conditions that are totally avoidable. For example, I die if you forget to
send a required argument. But I would not die in a parse() function that is
On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
[snip]
> IMO. Also, I don't think DT::Infinite is in the same boat, because
> that is a legitimate date (that DT::F::Simple must parse, BTW:
> /^([-+])?inf(?:inity)?$/i). Returning DT::Infinite is not an error!
Is infinity really a s
On 7/16/03 11:21 AM, Ben Bennett wrote:
> On Wed, Jul 16, 2003 at 10:15:46AM -0400, John Siracusa wrote:
> [snip]
>> IMO. Also, I don't think DT::Infinite is in the same boat, because
>> that is a legitimate date (that DT::F::Simple must parse, BTW:
>> /^([-+])?inf(?:inity)?$/i). Returning DT::In
On Wed, 16 Jul 2003, John Siracusa wrote:
> Here's my take on handling parse errors, and error handling in general.
>
> 1. I don't like to (unconditionally) die from within libraries except for
> conditions that are totally avoidable. For example, I die if you forget to
> send a required argument
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
> > > 2. My option:
> > > $day_of_month = ;
> > > $dt->set( day => $day_of_month )->truncate( to => 'day' );
> > > print "Your day must be a number in the current month" if
> > > $dt->is_undef;
> >
> > See, most people won't _bother_ with the 3rd li
On Tue, 15 Jul 2003, Joshua Hoblitt wrote:
> We were talking about returning DT::Undef objects from parsers. So, for
> example, if the _format_ being parsed _defines_ an unknown or undefined
> date/time an object can be returned that reflects this. Simply
> returning undef when an object is expe
Well, I don't think that the simple is supposed to indicate simple to
parse (at the moment the parser is all but simple... but I am trying
to clean it up). I read it as "simple formats", i.e. common formats
that define the date and time in fairly straightforward ways (month names
and numbers for t
On Tuesday, July 15, 2003, at 11:11 PM, Rick Measham wrote:
I'm an anti-fan of die. Die requires wrapping in eval or parsing the
user's input before passing to ->parse_datetime, which is just crazy.
We should only throw errors on programmer error. For example:
$dt->set( weekday => 'Frid
On 7/16/03 1:40 PM, Ben Bennett wrote:
> Well, I don't think that the simple is supposed to indicate simple to
> parse (at the moment the parser is all but simple... but I am trying
> to clean it up). I read it as "simple formats", i.e. common formats
> that define the date and time in fairly stra
John Siracusa schreef:
> On 7/16/03 1:40 PM, Ben Bennett wrote:
>
> What is the advantage of excluding things that are simple to parse, but not
> "conceptually simply"?
Not confusing the user who doesn't need it. If you want anything
complex, either to parse or to conceptualisate, then you're sup
On 7/16/03 2:16 PM, Eugene van der Pijll wrote:
> Most of the formatting modules don't know what to do with infinite dates.
That's a bug/feature in the formatting modules, IMO, not a reason to pretend
that infinite dates don't exist.
> Similarly, most of the programs using DT won't use infinite d
John Siracusa schreef:
> On 7/16/03 2:16 PM, Eugene van der Pijll wrote:
> > Most of the formatting modules don't know what to do with infinite dates.
>
> That's a bug/feature in the formatting modules, IMO, not a reason to pretend
> that infinite dates don't exist.
Infinite dates do not exist. (
> By puking all over them right then and there. While a "DT::Undef" object
> might be useful for some, it should not be used as a return value in the
> case of an error. People who want to use it can just do this:
I agree. I specifically DON'T want DT::Undef to be returned as an error condition
> Infinite dates do not exist. (And neither do undefined ones.)
If you accept that as dates or not, they are both valid pieces of information that
need to be expressed.
-J
--
On 7/16/03 3:39 PM, Eugene van der Pijll wrote:
> John Siracusa schreef:
>> On 7/16/03 2:16 PM, Eugene van der Pijll wrote:
>>> Most of the formatting modules don't know what to do with infinite dates.
>>
>> That's a bug/feature in the formatting modules, IMO, not a reason to pretend
>> that infin
Joshua Hoblitt schreef:
> > Infinite dates do not exist. (And neither do undefined ones.)
>
> If you accept that as dates or not, they are both valid pieces of
> information that need to be expressed.
Sure. If the programmer chooses to, by choosing modules that return
them.
But no part of DateTi
On Wed, 16 Jul 2003, Eugene van der Pijll wrote:
> But no part of DateTime, the base module, should return these non-dates.
> They should only be a result of some action where it makes sense that
> something else than a date is returned.
>
> Specifically, the default parser should not return these
John Siracusa schreef:
> On 7/16/03 3:39 PM, Eugene van der Pijll wrote:
> > Infinite dates do not exist.
>
> Infinite DateTime objects do, which was my point.
The Loch Ness monster exists. That doesn't mean that
DateTime::Format::Roman should accept it.
> > A Format object does not have to acce
On 7/16/03 4:17 PM, Eugene van der Pijll wrote:
>> I never suggested that ambiguous forms should be parsed by DT::F::Simple.
>
> Not even 04/05/2003?
That's not ambiguous, thanks to the handy setting in DT::F::Simple that
tells it exactly how to interpret that :)
>>> If "today" is parsed, people
> But no part of DateTime, the base module, should return these non-dates.
> They should only be a result of some action where it makes sense that
> something else than a date is returned.
I never have been in favor of the base module returning these. I'm just pointing out
that there is a niche
Eugene van der Pijll wrote:
> Oh, I forgot one: if "now" is parsed, "never" should be as well
> (returning DT::Undef). (That one is somewhat sensible to include, even.)
"now" is a DT, or a DT function
"never" is DT::Set->new_empty
"forever" is DT::Set( -inf, inf )
"undef" is DT::Undef
- F
> The Loch Ness monster exists. That doesn't mean that
> DateTime::Format::Roman should accept it.
Yes it does. It should accepts Dave's organic cucumbers too.
-J
--
Added to the FAQ.
Thanks!
-ben
On Thu, Jul 17, 2003 at 03:53:57PM +1000, Iain Truskett wrote:
> * Hill, Ronald ([EMAIL PROTECTED]) [15 Jul 2003 02:57]:
> > Hi John & Iain
>
> > > On Sunday, July 13, 2003, at 08:11 PM, Iain Truskett wrote:
> > > > Remember: part of the point of ha
58 matches
Mail list logo
