Change string 3

[rzs0502]

Hi All,

I'm very new to Perl and I have a question regarding adding characters to a string.

I am basically querying a table and one of the columns has a date stamp
eg. 20061107

What's the best way to convert this to 2006-11-07 ?

Thank you.



"If you always do what you've always done, you will always be where you've always been."

 

[stevexff]

Is it a real 'date' column? Or is it a CHAR or INT that just happens to hold a date? Most SQL implementations return a formatted string CCYY-MM-DD from a date column. If not, then

my $date = "20061107";
$date =~ s/^(\d{4})(\d\d)(\d\d)$/$1-$2-$3/;

Steve

[small]"Every program can be reduced by one instruction, and every program has at least one bug. Therefore, any program can be reduced to one instruction which doesn't work." (Object:erlDesignPatterns)[/small]

 

[MillerH]

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:

http://dev.mysql.com/doc/refman/5.1/en/datetime.html

http://dev.mysql.com/doc/refman/5.1/en/date-and-time-functions.html

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.

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.

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.

 

[rzs0502]

Thanks a lot guys!!

Working with a CISAM database so limited functionality on the database side...
I was about to rewrite in Python!!
I used MillerH's Solution 2.

Thanks again..




"If you always do what you've always done, you will always be where you've always been."