in reply to Re: Re: Date conversion with Class::DBI
in thread Date conversion with Class::DBI

I guess I don't quite get what you are trying to do then. To parse a date into a Time::Piece object you can use the strptime:

my $date = Time::Piece->strptime("01/02/2003",
                                 "%e/%B/%Y");
$t->created($date);

[download]

Where $t is a Class::DBI object with a 'created' column. With the has_a relationship you pass an object to the mutator, not a string. If you pass a string to the mutator, it will try to use the inflate method which will expect your date string to be in MySQL format. So just pass it a Time::Piece object which is what it is after anyway.

Now when you want to print it or retrieve it later on in the format you are after, you can use:

$t->created->dmy('/');

[download]

You don't have to worry about MySQL date formats at all, you just have to know how to create Time::Piece objects, and how to alter and access Time::Piece objects.

If you want these formats to happen automatically, then write a couple of functions that do the work for you:

sub parse_date {
  return Time::Piece->strptime(shift, "%e/%B/%Y");
}

sub stringify_date {
  return shift->dmy('/');
}

[download]

You could probably write a custom module that inherits from Time::Piece::MySQL and override the new and stringification subroutines with something like the above to make things a little more transparent.

If I am still misunderstanding what you are trying to accomplish, perhaps you could write a quick code sample of how you would like to use dates with Class::DBI.

- Cees

Updated: Fixed a dumb little typo

Replies are listed 'Best First'.
Re: Re: Re: Re: Date conversion with Class::DBI
by bsb (Priest) on Jul 08, 2003 at 00:14 UTC
    That's a good, clear explanation of what it going on.

    My issue is that I have customizable tables that I'm trying to handle generically and I wanted to avoid having to treat date columns differently. Either by calling methods or writing wrappers. I want the mutator to accept D/M/Y strings, even sloppy ones. Given all this, is has_a still what I'm after? Or is changing the accessor/mutator? (Or may I should just change my requirements)

    Also, this was partly an exercise in understanding Class::DBI for me. I didn't expect the inflate method to be used via the mutator.

    Thanks a lot anyway,
    Brad

    PS.You could probably write a custom module that inherits from Time::Piece::MySQL.
    Note that Time::Piece::MySQL doesn't actually inherit from Time::Piece. Time::Piece is a difficult base class.

[reply]

      Well, I can tell by your other responses that you are aiming for the 'change the mutator' option, but since you're still open for suggestions, I'll try to extend my suggestion to include your other requirements.

      Read more... (4 kB)

      Cheers,

      Cees

      ps I have enjoyed this endevour and thank you for the question. I have learned a bit more about has_a and what can be done with it, so even if you choose not to go this route, I am happy to have learned something myself :)

[reply]
[d/l]
[select]
        Another great post.

        It's nice to know it can be done. I may even end up doing it this way now.

        You are still dealing with an object, so you need to be careful when passing it to other functions if they expect a string

        I was thinking about tie-ing a scalar but that's one of my personal red-flags-to-insanity so I stopped.

[reply]

In Section Seekers of Perl Wisdom