I think MySQL::DateReformat might be a more appropriate module name.
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
>
>
>
