On Thu, 1 Nov 2001, Tim Bunce wrote:
> I think MySQL::DateReformat might be a more appropriate module name.
Hi Tim.
WRT the name (leaving aside the debate about usefulness!), I noted that
there is no 'MySQL' namespace on CPAN, sadly, but only 'Mysql' (even
'mysql' would be better IMO) ... and there are only the DBD modules in
there.
As to whether the code should ever have been written, or whether it is
sacrilege not to use Date::Format or Time::Piece or some such, and whether
laziness is no longer a virtue for a Perl hacker, I refer you to
[EMAIL PROTECTED] on c.l.p.m ... :)
- nick
>
> Tim.
>
> On Wed, Oct 31, 2001 at 09:55:23PM -0800, Nick Tonkin wrote:
> >
> > On Thu, 1 Nov 2001, Philip Newton wrote:
> >
> > > Disclaimer: I am not a PAUSE admin.
> > >
> > > On Wed, 31 Oct 2001 14:44:04 -0800 (PST), in perl.modules you wrote:
> > >
> > > > Date::MySQL -- Manipulate dates back and forth between
> > > > human-readable and MySQL formats
> > >
> > > Um, I think you *really* should discuss this on [EMAIL PROTECTED] before
> > > submitting this module to CPAN. There are, at last count, about two
> > > squillion modules already on CPAN which deal with dates in some form or
> > > another. That mailing list should help you determine whether your
> > > module's functionality deserves a separate module, what its name should
> > > be, or which module it could be merged into.
> >
> > Um, I sent an RFC there too.
> >
> > >
> > > For example, parsing dates is handled by Date::Parse [among others] and
> > > outputting them in various formats by Date::Format [among others], both
> > > from Graham Barr's TimeDate distribution.
> > >
> >
> > Um, I talked with Graham about it too. He said: "The module seems fine,
> > but I don't think it belongs under Date::Format. Maybe just Date::MySQL"
> >
> > > > SYNOPSIS
> > > > use Date::MySQL;
> > > > my $md = Date::MySQL->new();
> > > > print $md->toMySQL("5/31/87"); # prints "1987-05-31"
> > > > print $md->frMySQL("1987-05-31"); # prints "05-31-1987"
> > >
> > > I can imagine (without having tested this) that these could be reduced
> > > to something like
> > >
> > > use Date::Parse;
> > > use Date::Format;
> > > print time2str("%Y-%m-%d", str2time('5/31/87'));
> > > print time2str("%m-%d-%Y", str2time('1987-05-31'));
> > > # or if you want DD/MM/YY:
> > > print time2str("%D", str2time('1987-05-31'));
> > >
> > > That wheel has already been invented -- and in more flexible ways, to
> > > boot.
> >
> > This is just supposed to be a tool to do one thing cleanly and
> > easily. I'm well aware of the Date::Parse and Date::Format modules, and
> > made mention in my post that I am aware there are multiple ways to do
> > this.
> >
> > In my experience it has proven much more convenient to encapsulate these
> > routines in their own little package that can be used throughout multiple
> > applications, etc. I believe that others may find the same thing to
> > be true. Not all others, and evidently not you. Just some others.
> >
> > >
> > > > DESCRIPTION
> > > > The MySQL RDBMS requires dates to be supplied in
> > > > YYYY-MM-DD format[1,2], but humans expect dates to be
> > > > presented, and to be able to enter them, in MM-DD-YY
> > > > format or similar. This module converts dates back and
> > > > forth between human-readable and MySQL format.
> > >
> > > Um, make that: *some* humans. MM-DD-YY is common in America, but much of
> > > Europe prefers DD-MM-YY, and Japan uses YY-MM-DD. A format allowing you
> > > to specify the order of the date parts would be better, in my opinion.
> >
> > Um, did you bother to RTFM before slamming this proposal? The module
> > allows you to specify several format options (e.g. like this: $md =
> > Date::MySQL->new(format=>'euro') ...), and if you prefer to have
> > the year at the beginning you can always not use the code at all.
> >
> > >
> > > And even though my "native" date order is DD-MM-YY (I'm in Germany), I
> > > have no problem with YYYY-MM-DD (but that may be because I'm a
> > > programmer and like that format for its sorting properties), so I don't
> > > "expect dates to be presented, and to be able to enter them" in another
> > > way.
> >
> > Yes, well, unfortunately as a programmer I find that, suprisingly,
> > non-programmers often use my applications. Therefore I make the interface
> > convenient for them.
> >
> > - nick
> >
> >
> >
>
