On Thu, Nov 01, 2001 at 07:28:31AM -0800, Nick Tonkin wrote:
> 
> On Thu, 1 Nov 2001, Tim Bunce wrote:
> 
> > I think MySQL::DateReformat might be a more appropriate module name.
> 
> Hi Tim.

Ah, you're 'the' Nick Tonkin! (the tonkinresolutions.com threw me off :-)

Hi Nick!

> 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. 

Umm, this says otherwise:

    http://search.cpan.org/search?mode=module&query=mysql%3A%3A

But shows that both MySQL:: and Mysql:: are being used.
And both by more than one module and author. Oh dear.

> 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 ... :)

I don't read usenet anymore and groups.google.com doesn't find it:
http://groups.google.com/groups?as_umsgid=3be16592.1204364484%40news.silcom.com
:-(

Tim.

> - 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
> > > 
> > > 
> > > 
> > 
> 

Reply via email to