in reply to Converting MySQL datetime values to DateTime objects

According to the source code, the new() constructor for DateTime::Format::DBI is just a front-end factory that will return one of the format classes based on the nature of your $dbh. So in your case, what you're actually getting is an instance of DateTime::Format::MySQL, except you weren't supposed to have to think about that.

The docs list DateTime::Format::MySQL in the 'see also' section. This relationship with the other format classes should probably be more explicitly mentioned for the benefit of those not accustomed to factories (or polymorphism...depending on how much the various format classes agree with each other's API.)

I'll forward the observation to the DateTime Project mailing list.

Matt

  • Comment on Re: Converting MySQL datetime values to DateTime objects

Replies are listed 'Best First'.
Re: Converting MySQL datetime values to DateTime objects
by jonadab (Parson) on Jul 19, 2003 at 15:57 UTC
    what you're actually getting is an instance of DateTime::Format::MySQL, except you weren't supposed to have to think about that.

    Yes, I gathered that much, but shouldn't all of the classes it might return (depending on the db backend used) have a parse_datetime function, and shouldn't usage for this function be normalised across all of them and documented in DateTime::Format::DBI's documentation? It shows how to do the conversion the other direction, without caring which database is on the backend. Why not in this direction also? I was assuming that the underlying classes all simply implemented the things required by the general class in whatever manner is necessary for their respective backends. Apparently this is not the case?


    Quidquid latine dictum sit altum viditur.
      Here is the response to my note on the mailing list -- you might find it of interest. Now's a good time to get involved with the DateTime project!

      Matt