On Fri, 21 Mar 2003, Dave Rolsky wrote:
> On Fri, 21 Mar 2003, Joshua Hoblitt wrote:
>
> > > I honestly don't see the point. I'm not trying to write code for use by
> > > MySQL itself ;) I just want to provide something that makes interfacing
> > > with MySQL easier.
> >
> > I often accept input, modify it some how (offsets, etc), and then pass
> > it on to MySQL. It is totally reasonable to accept the same formats as
> > MySQL itself. Since this is a very minor modification I don't
> > understand your resistance.
>
> I dunno, it just seems weird to me to have this module act as if it were
> MySQL. If you show me a use case (in code) I'll apply your patch. I just
> want to see how it'd be used.
I've given this some thought and I do indeed agree with your point of view. However
now I think that there is a need for a separate module that accepts all same inputs as
MySQL. :)
My usage pattern involves a lot of massaging timestamps (often from flat files) before
stuffing it into a DB. This timestamps are almost always in a format the MySQL will
understand but not necessarily in the 'strict' Format.
--
while ( <FILE> ) {
chomp;
my( $time_hst, ... ) = split / /;
my $date = Date::Manip::ParseDate( $time_hst );
my $new_date = Date::Manip::Date_ConvTZ( $date, "HST", "UTC");
my $time_utc = Date::Manip::UnixDate( $new_date, "%Y-%m-%d %H:%M:%S" );
( do stuff )
( commit to db )
.
.
--
If the intent is for DateTime::Format::MySQL to parse _only_ the output format from
MySQL. Then perhaps a DateTime::Filter::MySQL that can sit in front of MySQL more or
less transparently? While I believe you could argue that this is a special case and a
custom parsers should be written I suspect that this situation arises fairly
frequently.
Or maybe the namespace suggested in a different thread. DateTime::Parse::MySQL???
Cheers,
-J
--
