PHP programming forum. Ask questions or help people concerning PHP code. Don't understand a function? Need help implementing a class? Don't understand a class? Here is where to ask. Remember to do your homework!
for($i=0;$i<20; $i++) {
$subject = mysql_result($result,$i,'t1.Notice_Title');
$description = mysql_result($result,$i,'t1.Notice_Text');
// Clean the description
$description = str_replace ("&","",htmlspecialchars(strip_tags($description)));
$link = mysql_result($result,$i,'t1.Notice_Link');
//to record when the feed was published
$pubdate = mysql_result($result,$i,'t2.publish_up');
//format the date
$format = 'm/d/Y'; //or what ever format you choose (see the reference below)
$pubdate = date_format(date_create($pubdate), $format);
echo '
<item>
<title>'.$subject.'</title>
<link>'.$link.'</link>
<description>'.$description.'</description>
<pubDate>'.$pubdate.'</pubDate>
</item>
';
} //end of the for-loop
2), 3) ,4) are invalid in this instance because this is for an RSS reader, so the date has to be in the RSS accepted standard format. 1) is a valid concern
Real programmers don't comment their code. If it was hard to write, it should be hard to understand.
I don't think 1) is much of a reason either. People rarely, if ever, convert from one database to another. And when you do you have to review all the SQL anyway and are sure to catch any functions used. I agree that 2), 3) ,4), which are all about pushing the date format into the template are very valid reasons if there is a need for creativity in date formatting. Usually app centralize this kind of formatting so it can be changed site-wide with a setting and not have to dig through templates, especially for 3).
Christopher wrote:I don't think 1) is much of a reason either. People rarely, if ever, convert from one database to another. And when you do you have to review all the SQL anyway and are sure to catch any functions used. I agree that 2), 3) ,4), which are all about pushing the date format into the template are very valid reasons if there is a need for creativity in date formatting. Usually app centralize this kind of formatting so it can be changed site-wide with a setting and not have to dig through templates, especially for 3).
And especially if you use an ORM, then they have abstracted SQL (Hibernate HQL, Doctrine DQL etc) accross platforms as well in which case 1) is not a reason at all
2), 3), 4) could be a reason if your building a UI app but I aggree with pickle, when it's a standard-acceptable format.
Yes, definitely 2,3,4 are irrelevant in this instance. As far as 1, after I spent several painful months to convert a whole app to work with both MySQL and SQL Server, I made it a rule to always use standard SQL that works across platforms. And yes, when you use an ORM, that becomes a lot easier.
I would also add a #5: separation of concerns. The code that interacts with the database should know nothing about how the data is presented. You may have many display adapters for the same exact data (e.g. mobile html, json api, xml api, xls, etc.) Now of course you will probably use strtotime on the data sometime after you get it from the database (so it doesn't hurt anything that the database is formatting the date) but the concept of separating concerns is important.
I just wanted to make a point to any noobs coming across Christopher's comment that you shouldn't interpret his suggestion as a general best practice to format dates at the database level.