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 "tomorrow" to be parsed as well"
>>
>> Well, you could just set a policy to avoid anything that requires date math.
>
> Is DT::truncate date math? If so, this disqualifies "today"...
You don't necessarily need to use truncate to handle "today" (e.g. It could
just be documented to mean 00:00:00), but no, I wouldn't consider truncation
to be "date math."
> Oh, I forgot one: if "now" is parsed, "never" should be as well
> (returning DT::Undef). (That one is somewhat sensible to include, even.)
...unless you consider all such things to be "deranged monstrosities"! :)
On 7/16/03 4:16 PM, Dave Rolsky wrote:
> End users should not be getting back DT::Inf or DT::Undef (if the latter
> eventually exists) unless they explicitly declare that they are working
> in a domain where such things exist.
Like I said earlier, if your code accepts DateTime objects, but doesn't want
to deal with infinite dates, then you've got to explicitly check for
finite-ness anyway. I don't think you can just *assume*, based on a choice
(default or otherwise) of DT::F:: modules, whether or not infinite dates
will ever cross their (code) path.
If you want to put the onus on the user to read the particular DT::F::
module's documentation to see what kinds of DateTime objects could possibly
be returned, then users will have to do the same for DT::F::Simple. And in
that case, DT::F::Simple just has to document what it can return.
Finally, if you're just trying to go for the "principle of least surprise",
then I don't think a programmer would be surprised that
DateTime->parse('infinity');
returns an infinite date! It's not like infinite dates are going to just
start spewing fourth from DateTime->parse() randomly :)
-John
