It appear that you are right about this. For example,
DateTime::Format::Natural like most of the Format modules instantiates
a DT object early on with ->now() and so all information on
presence/absence of datetime components in the source is already gone
by this point, even if you do augment DateTime itself (I tried, it
works). Hmm, this is very frustrating, it would seem to be a simple
task, to parse into an object and set some variables depending on
whether there was a day/month in the source data. It's impossible
unfortunately - I'm thrown back on parsing dates myself which is
rather silly when I really need to use DateTime::Format::Natural. I'm
amazed nobody has raised this before. The issue in a nutshell is - by
the time you have a DateTime object via a DateTime::Format module, how
do you tell if day/month/hour/minute/second were present in the
original data? The unfortunate answer is ... you can't.

PK

On 24 February 2011 10:40, Zefram <zef...@fysh.org> wrote:

> Extending DateTime to cover
> DateTime::Incomplete's job, however, would be neither necessary nor
> sufficient: you'd still need DateTime::Format::* extended to pass along
> information about incompleteness



-- 
Dr Philip Kime

Reply via email to