[Dbix-class] Re: DateTime objects passed to search() are not supported properly

[Peter Rabbitson]

On Thu, Sep 20, 2012 at 12:56:30PM +0200, Alexander Hartmaier wrote:
> On 2012-09-20 12:22, Peter Rabbitson wrote:
> > On Wed, Sep 19, 2012 at 07:06:19AM -0700, Bill Moseley wrote:
> >> On Wed, Sep 19, 2012 at 3:36 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>wrote:
> >>
> >>> It never had a method to format it correctly in *all* cases. It can format
> >>> it correctly 95% of the time (this is not really fixable either, it's an
> >>> architectural deficiency). Hence the warning and leaving it to the user to
> >>> make sure they are getting what they expect.
> >>>
> >> Hi Peter,
> >>
> >> I guess what is confusing to me is if I can ask the storage object for the
> >> datetime_parser and use that (as per the cookbook) then why wouldn't DBIC
> >> be able to use that directly as well?
> >>
> >> Is the parser from the storage object the parser (formatter) that you are
> >> saying might not get it right?
> >>
> >> If the format is that far off won't the database complain?  The problem
> >> I've experienced is where the default format doesn't include the time zone
> >> so the time ends up in the database server's timezone in error.
> > Precisely. The problem is that we can not invoke the correct IC::DT
> > deflation routine to respect possible time_zone settings. The formatter is
> > fine for use only as that - a formatter. There is no practical way to tie
> > the IC::DT metadata to your search criteria. There is no change in behavior
> > - DBIC has always done the wrong thing (simply stringifying the DT object).
> > What changed is that now you are getting a warning about it.
> Oracle's Datetime datatype doesn't store a timezone information so you
> need to make sure you always convert to the same, UTC in my case.
> I don't get the problem at hand, because the InflateColumn components
> specify a serializer, why can't it be called on the object?
> In case the serializer needs to know metadata about the column like the
> timezone in case of a DataTime?
> Why not enable the serializer to access the the column_info?

Read the API of the serializers, especially the deflator. Especially what is 
the 2nd argument passed to it. Then think hard why this is an insurmountable 
problem.

Clue - to make this possble you *have* to rewrite the way IC::DT deflators 
work (but keep the rest of the IC system intact). This gets very messy 
very fast.

Bonus clue - even if you fix the special case of IC::DT, you are still left 
with not being able to use the rest of the IC system transparrently in 
search() arguments. I am really not sure if there is any viable solution to 
this, beyond a time machine.