[Dbix-class] Pointless update on a date field
Matt S Trout
dbix-class at trout.me.uk
Wed Sep 19 17:10:49 GMT 2007
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
> 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?
More information about the DBIx-Class