[Dbix-class] Pointless update on a date field

[Matt S Trout]

On Tue, Sep 18, 2007 at 10:05:14PM +0100, Richard Jones wrote:
> Matt S Trout wrote:
> >>I have:
> >>my ($yr, $month, $day) = Date::Calc::Decode_Date_EU($date);
> >>return DateTime->new( year => $yr, month => $month, day => $day);
> >
> >There's almost certainly a DateTime::Format module that'll do better than
> >that - the strptime one for a start. Trying to use Date::Calc stuff to get
> >to DateTime objects is always going to be more work since you're now hand
> >linking two separate projects with incompatible APIs.
> >
> >I often use Time::ParseDate which gets me an epoch value then construct a
> >DateTime object from that (and it'll usually DWIM however the date's 
> >supplied)
> >
> 
> Time::ParseDate works nice, providing dates are >= epoch (1970-01-01). 
> But it's not much use for dates of birth, at least for an adult 
> population. For a date before 1970, Time::ParseDate parsedate() does 
> generate the $no_of_seconds_since_epoch (a negative number), but 
> DateTime->from_epoch( epoch => $no_of_seconds_since_epoch ) dies as it 
> seems unable to handle a negative number of seconds.

That's a bug. Report it to DateTime's rt queue and see about sorting out
a patch (I just checked with the author and he's happy to take one).
 
> DateTime::Format::Strptime *can* handle dates before the epoch, but it 
> needs the date pattern specifying, thus lacking the flexibility provided 
> by Date::Calc::Decode_Date_EU.
> 
> So, it seems Date::Calc is a better option for generating a DateTime 
> object from a form field where the user is not restricted to a 
> particular date format.

I'd vote for fixing DateTime as being even easier personally :)

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director                    http://www.shadowcat.co.uk/catalyst/
 Shadowcat Systems Ltd.  Want a managed development or deployment platform?
http://chainsawblues.vox.com/            http://www.shadowcat.co.uk/servers/