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
Well, there are only two modules: DT::F::MySQL and DT::F::Pg.
I'd really like to see a lot more database formatters.
I'm willing to do DT::F::DB2.
That still leaves several major DB's unsupported:
Oracle
SQL Server
Sybase
And all the minors:
mSQL
SQLite
InterBase
Pheonix
SAPs DB
Access???
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
Ben Bennett [EMAIL PROTECTED] schrieb/wrote:
On Wed, Jul 16, 2003 at 12:05:00PM +0200, Claus Färber wrote:
Not all languages use suffixes when writing numbers. In German, for
example, you'd just write 14. Juli. (Actually, it's spoken
vierzehn*ter* Juli, but one does not write 14ter Juli; in
Hi Dave,
[snipped]
The test was wrong, I believe. Either that or the locale had
a bug that is now fixed.
yes, It now passes on 5.8.0
[more snippage]
I can't stress this enough. When tests fail, please rerun
the tests with 'make test TEST_VERBOSE=1 TEST_FILES=t/...'
This gives
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
On Wed, 16 Jul 2003, Joshua Hoblitt wrote:
Pheonix
First of all, it's Phoenix, and second of all, you're thinking of
Firebird. Don't get that name wrong or they'll come down on you like a
ton of bricks ;)
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
Joshua Hoblitt schreef:
Well, there are only two modules: DT::F::MySQL and DT::F::Pg.
I'd really like to see a lot more database formatters.
snip 10 other databases
Do all of these have different datetime formats? If database X has the
same formats as e.g. Pg, it doesn't need a separate
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 =
Claus F?rber schreef:
Rick Measham [EMAIL PROTECTED] schrieb/wrote:
It's in the year 3 A.D. Period. This is a 'simple' module so I don't
think it should try bending user input too much. If you assume it to be
2003, then how do I say it's the year 3?
02/11/0003
Nope. With that input,
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
First of all, it's Phoenix, and second of all, you're thinking of
Firebird. Don't get that name wrong or they'll come down on you like a
ton of bricks ;)
Your right - I'd been traveling for 24 hours. :)
-J
--
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
--
In a thread long ago we'd had discussed the possibility of breaking up the DT
constructor(s) to be a little more friendly to sub-classing. Specifically so the
validation behavior could be modified. Here is an example of changes to new() to
allow this. What do you think about something like
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:
Do all of these have different datetime formats? If database X has the
same formats as e.g. Pg, it doesn't need a separate format. Of course
DT::F::DBI should know about these cases.
If X has identical date/time handling as Pg I'd like to see DT::F::X
be isa
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
--
32 matches
Mail list logo
