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
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 :)
If all
* 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
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
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)
. have
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 wrong
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
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 = STDIN;
$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 line in option 2!
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
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
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 =
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
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 infinite dates
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 DateTime,
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 accept
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 expect
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
- Flavio S. Glock
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
--
* 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
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 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.
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
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 simple
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
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
40 matches
Mail list logo
