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