Date::MySQL 
Author Message
 Date::MySQL

Hi,

From the docs on this module:

NAME
       Date::MySQL -- Manipulate dates back and forth between
       human-readable and MySQL formats

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"

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.

[ ... ]

Obviously the basic functionality here could be accomplished by other
generic methods. The module's goal is to make it very easy to go back
and forth between these two formats, with error checking built in. It
also provides several optional format controls.

Full documentation is available at
http://www.*-*-*.com/

Thanks for any feedback.

- nick



Mon, 19 Apr 2004 06:48:30 GMT  
 Date::MySQL

Quote:

> Hi,

> From the docs on this module:

> NAME
>        Date::MySQL -- Manipulate dates back and forth between
>        human-readable and MySQL formats

> SYNOPSIS
>         use Date::MySQL;

use Time::Piece;

Quote:
>         my $md = Date::MySQL->new();
>         print $md->toMySQL("5/31/87");    # prints "1987-05-31"

print Time::Piece->strptime("%D", "5/31/87")->strftime("%Y-%m-%d");

Quote:
>         print $md->frMySQL("1987-05-31"); # prints "05-31-1987"

print Time::Piece->strptime("%Y-%m-%d")->strftime("%m-%d-%Y");

Note that your US-centric view of the world (nobody but the US formats
dates like you have) really shouldn't be shoehorned into a module.

See also man strftime and man strptime.

Matt.



Mon, 19 Apr 2004 18:17:41 GMT  
 Date::MySQL


Quote:

>> From the docs on this module:
[...]
>>         print $md->toMySQL("5/31/87");    # prints "1987-05-31"

>print Time::Piece->strptime("%D", "5/31/87")->strftime("%Y-%m-%d");

>>         print $md->frMySQL("1987-05-31"); # prints "05-31-1987"

>print Time::Piece->strptime("%Y-%m-%d")->strftime("%m-%d-%Y");

>Note that your US-centric view of the world (nobody but the US formats
>dates like you have) really shouldn't be shoehorned into a module.

RTFM shows that the user can set the output format to 'euro' and
others, and control other aspects of the presentation and calculation.
But then you obviously didn't RTFM, even though I provided the URI.

Sorry for the snippy attitude, but your comment was much less than
helpful. As I said, I'm well aware that there are a million ways to
format time and date. Before creating this little package I used
Date::Parse and Date::Format. The method you suggest is alright too.

However, I have found it easier to encapsulate the routines in a small
package. It's a lot easier for me to remember a method call like
$obj->frMySQL(...) than the correct format strings for something like
Time::Piece or Date::Format. I'm less likely to make a typo too.

I don't believe that every new module needs to handle an as yet
untackled task. It just needs to make life easier for the user. My own
experience is that it's sometimes easier for me to use a tool custom
built for my task than to use the giant swiss army knife and probably
break a fingernail trying to get the right blade out. You obviously
don't feel that way, and that's fine by me.

It _is_ problematic, IMHO, that the fora for comments on proposed
modules seem to consist almost exclusively of heavy gurus, such as
yourself, for whom a module such as the one I have proposed is
superfluous, at best ... when there is a much larger group of less
skilled programmers who would be glad to have one less task to worry
about. It would be more instructive if one could get feedback from
that group as well.

By the way, I was born and raised in Newcastle, County Durham (as it
was then), am quite familiar with several conventions for printing
dates, and resent being called "US-centric" more than almost any other
insult you could throw my way.

- nick



Mon, 19 Apr 2004 23:23:46 GMT  
 Date::MySQL

Quote:

> Sorry for the snippy attitude, but your comment was much less than
> helpful. As I said, I'm well aware that there are a million ways to
> format time and date. Before creating this little package I used
> Date::Parse and Date::Format. The method you suggest is alright too.

If you are proposing a module that accomplishes things already
accomplished by other modules, then your proposal should include
information on what those other modules are and what the difference is
between those modules and the one you are proposing.  If you don't do
that, it is really the job of this forum to do that for you.

Quote:
> It _is_ problematic, IMHO, that the fora for comments on proposed
> modules seem to consist almost exclusively of heavy gurus ...

Well that isn't true, otherwise I wouldn't be here.  But here's the
advantage of having people with a wide knowledge comment on modules --
it keeps us from being penny wise and pound foolish, which is how I
would see your module.  Yes, yours makes it slightly easier to
accomplish the one specific task in that one specific environment.  But
what happens when that script needs to be used with a different
database?  Or when the programmer who learned to deal with the problem
using your module moves to a different job where a different database is
used?  Wouldn't a more generic date conversion routine be more useful in
both those circumstances?

Quote:
> By the way, I was born and raised in Newcastle, County Durham (as it
> was then), am quite familiar with several conventions for printing
> dates, and resent being called "US-centric" more than almost any other
> insult you could throw my way.

I sympathize.  I was born in St. Louis, Missouri, USA and I feel the
same way. :-)

--
Jeff



Tue, 20 Apr 2004 00:04:18 GMT  
 Date::MySQL


Quote:

>> Sorry for the snippy attitude, but your comment was much less than
>> helpful. As I said, I'm well aware that there are a million ways to
>> format time and date. Before creating this little package I used
>> Date::Parse and Date::Format. The method you suggest is alright too.

>If you are proposing a module that accomplishes things already
>accomplished by other modules, then your proposal should include
>information on what those other modules are and what the difference is
>between those modules and the one you are proposing.  If you don't do
>that, it is really the job of this forum to do that for you.

Well, fair enough, but I did make reference in my original RFC to the
fact that there are other ways to do this. But isn't that the Whole
Point about Perl? I imagine one could avoid using a single module on
CPAN and still accomplish anything ... why do I need AxKit (e.g.) when
I have print() ?

Quote:

>> It _is_ problematic, IMHO, that the fora for comments on proposed
>> modules seem to consist almost exclusively of heavy gurus ...

>Well that isn't true, otherwise I wouldn't be here.  But here's the
>advantage of having people with a wide knowledge comment on modules --
>it keeps us from being penny wise and pound foolish,

You bet.

Quote:
> which is how I
>would see your module.  Yes, yours makes it slightly easier to
>accomplish the one specific task in that one specific environment.  But
>what happens when that script needs to be used with a different
>database?  Or when the programmer who learned to deal with the problem
>using your module moves to a different job where a different database is
>used?  Wouldn't a more generic date conversion routine be more useful in
>both those circumstances?

Well, I suppose you are right, in one way of looking at it. No doubt.
But the script will still have to be changed if the environment moves
to a DB server that requires dates in another format, even if it's
supplying a new format string to Date::Format or whatever. And the
programmer should first and foremost know how to solve the problem at
hand with the best tool available.

Maybe the approach I took was too narrow. But the built-in error
checking, four-digit-to-two-digit conversion rule configuration, and
other little features would need to be replicated somewhere, at least
in the applications I develop, and so you'd have to have a package of
reusable code somewhere to do more than just "print
time2str("%Y-%m-%d", str2time('5/31/87'));" or similar throughout your
code.

I for one have found a definite need for a simple filter between the
data store and the human user. And since I control the application
development environment in all the work I do (I just choose to work
that way), I am comfortable using a MySQL-specific tool in my
applications. You are quite right that for some people that may be a
trap.

Quote:

>> By the way, I was born and raised in Newcastle, County Durham (as it
>> was then), am quite familiar with several conventions for printing
>> dates, and resent being called "US-centric" more than almost any other
>> insult you could throw my way.

>I sympathize.  I was born in St. Louis, Missouri, USA and I feel the
>same way. :-)

Ah, yes, Ole Missou, which used to be the home of the gateway arch and
a great crossroads between Chicago and Delta blues, but is now the
home base of the B-2 stealth bombers :-}


Tue, 20 Apr 2004 00:45:55 GMT  
 Date::MySQL

Quote:

> Maybe the approach I took was too narrow.


anyone else is working on more generic database date conversion methods.

Quote:
> Ah, yes, Ole Missou, which used to be the home of the gateway arch and
> a great crossroads between Chicago and Delta blues, but is now the
> home base of the B-2 stealth bombers :-}

No need to rub it in :-)

--
Jeff



Tue, 20 Apr 2004 01:30:36 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Date Conversion from seconds to MySQL Date

2. Insert date into mysql-database

3. Weirdness with DBI, MySQL and dates not being quoted

4. Does DBD:mysql support transactions (mysql 3.23 does)

5. Inserting binary files into mysql database with DBD::mysql

6. Please help: installing mySQL and DBD::mySQL on separate boxes

7. DBD::mysql not loading mysql.dll

8. DBI (DBD:mysql) and Mysql ENUM Datatype question

9. DBD::mysql::st execute failed: Lost connection to MySQL server

10. DBI:mysql error: install_driver (mysql) failed

11. install dbd::mysql without installing mysql ??

12. Using perl's modules DBD:Mysql and DBI and mysql

 

 
Powered by phpBB® Forum Software