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+d...@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. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk