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 don't exist.
> 
> Infinite dates do not exist.

Infinite DateTime objects do, which was my point.

> A Format object does not have to accept every deranged monstrosity that
> is subclassed from DateTime. For example, my Format modules are
> documented to accept DateTime objects.

DateTime::Infinite is a "deranged monstrosity" now!?  Yeesh :)  Regardless
of your opinion of it, DateTime::Infinite is very useful to many people.

> this means that DT::F::Simple would try to be two things:
> 
> 1) it wants to parse all common datetime strings that a (naive?) user
> would pass to the program. To do this, it has to be as lenient as
> possible, whilst being aware of locale issues, and if possible, it
> should be able to interpret the most likely meaning of defective input
> like 01/02/03. It should be able to parse such simple phrases as 'now',
> but not unintuitive mathematical concepts.
> 
> 2) it wants to provide a shorter constructor. To do this, it should be
> exactly defined how formats are interpreted. Special phrases are
> provided to construct some special DT constructs (aka deranged
> monstrosities), like '+inf' and '-inf'. It is not necessary to duplicate
> other methods, so e.g. 'now' is not needed; DateTime::now() is perfectly
> adequate.
> 
> Combining these two aims is perhaps possible.

I never suggested that ambiguous forms should be parsed by DT::F::Simple.
The two-digit years thread was started by someone else :)  I think it should
parse common, unambiguous, easy to parse date strings.

> Calling the result Simple is a chutzpah.

Like I said earlier, maybe ::Basic is better.  But ::Simple is how we've
been discussing it so far, so I'm trying to avoid confusion :)

> Making it the default for DT parsing...

...is the key feature of the whole system!  (That's what you were going to
say, right? ;)

> 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.
But if you do want to accept "tomorrow", DT makes it pretty easy with
$dt->add(days => 1), unless I'm missing something... :)

-John

Reply via email to