Best is subjective
There are basically three approaches:
1) Let the database do the formatting
2) Using Perl, treat the date as a string and reformat it.
3) Using Perl, treat the date as a date and apply a format.
4) Some variant/combination of #2 and #3
Each of the approaches has benefits and failings. You're basically deciding up front where and if you want flexibility. You're also setting a precedent for how you want to deal with formatting for other dates in your system. This is definitely one of those things that is ultimately all about preferences.
Solution 1 - Let the database do the formatting.
I note that you called the field a DATE STAMP. I'm unfamiliar with that specific data type, so am unable to suggest any functions. If you were using MySQL (which I do), I would simply point you to the following references:
Solution 2 - Using Perl, treat the date as a string and reformat it.
The problem with this method is that you are making huge assumptions that limit your ability to change the way that the date is saved at a later date. The benefit is that it's the least amount of code and easily changed. It also adds no dependency on other modules, which is a good thing for simplicity sake.
Code:
my $datestamp = '20061107';
my $formatted = join '-', unpack 'a4a2a2', $datestamp;
print "$datestamp to $formatted\n";
Solution 3 - Using Perl, treat the date as a date and apply a format.
This is the most fun if you're going to be doing a lot of date formatting operations. It's also the most complicated, so if you don't need it stay away.
Code:
use Date::Parse qw(strptime);
use POSIX qw(strftime);
my $datestamp = '20061107';
my $formatted = strftime('%Y-%m-%d', strptime($datestamp));
print "$datestamp to $formatted\n";
The reason I why I would personally be reluctant to go this particular route is because strptime (read string Parse time) makes one very small assumption. It assumes that dates are in americanized format, IE that the month comes before the day in MM/DD/YYYY. In european format the day comes first. Because there is no definitive way to determine which format is being followed in this special case, it is therefore has to assume unless you explicitly specify
It's also true that both of strptime and strftime are slower because of their generalization.
Solution 4 - Some variant/combination of #2 and #3
You can add code to prevent the use of either strptime or strftime in the above example. You might consider doing the separation of the string into it's constituent parts yourself using unpack like in the first example. But then use strftime to format the data. Once again, I don't know why someone would choose to do this, but it is an option, and I expect that someone has made this choice for whatever reason.
Conclusion
Personally, I would go with #2 in this case. It gives you example what you need with minimum fuss. You should make sure to take into account the special case of if your date is null or '00000000', but that should be easily handled.
Good luck.
erlDesignPatterns)[/small]