Ok, I know I did a Zeus POTW earlier this week, but I had to share this little gem. This is another small thing - a simple function - and something that's been possible via a CFLib UDF for years. That being said - when I saw this show up in the latest Zeus build today, I had to share.
If you've ever needed to format a date and a time, you know that it requires two calls, ala:
<cfoutput>
#dateFormat(now())# #timeFormat(now())#
</cfoutput>
Zeus adds dateTimeFormat to combine this into one call:
<cfoutput>
#dateTimeFormat(now())#<br/>
</cfoutput>
For formatting, the mask is slightly different than before. Masks are based on SimpleDateFormat from Java. So for example:
<cfoutput>
#dateTimeFormat(now(), "MMMM d, yyyy h:mm a")#<br/>
</cfoutput>
Yeah, ok, not Earth-shattering, but this was one of a few new functions released in the latest Zeus build that were things I've seen requested for years.
Archived Comments
LSdateTimeFormat? :)
I didn't show it - but there is a 3rd arg - locale:
#dateTimeFormat(now(), "MMMM d, yyyy h:mm a","fr")#
Outputs: décembre 20, 2011 10:33 PM
> For formatting, the mask is slightly different than before.
You mean that I can't combine the variables dateFmt="yyyy/mm/dd" and timeFmt="HH:mm" (the values are internationalized for each installation) I already have? That would be a bad idea. CF should be compatible to itself.
@Atan -
I think what he's saying is that the mask format is different only for the new function. Coldfusion would need a way to discern date vs. time placeholders. If you look, the only ones that are actually different are the placeholders that are shared between both date and time masks.
That being said, your HH:mm would still produce a perfectly valid military time formatted time string. However, If I am taking this in properly, "yyyy/mm/dd" would actually generate "2011/[current minutes]/21" It would need to be "yyyy/MM/dd" for use in this new formatting function.
I could be wrong on all this, though. Just a thought.
Confirmation Ray?
Not sure I can confirm this as I wasn't involved in the engineering, but it sounds right to me. ;)
Since this is just a string value that tells the function how to format the output they should make the older functions for time and date formatting recognize the newer versions of the masks. The masks for the combined date and time format function need to be recognized by the older functions so you can set global formatting variables for date and time. I think this is what Atan meant by his post. The old functions should still recognize the old versions of the masks for backward compatibility, however, having the new masks supported is something I see as a "no brainer" for the development team to implement and should not be overlooked.
-Az
Finally! This is nice :-)
You're right in that it's not earth shateringly big of a change that I'm going to want to go back to old projects and update but you know what? It's useful and easy so I see no reason not to use it in the future ones.
Like it, I so want to see this being used more aggressively and staring to support different international calendars. That would be amazing. When you are looking at an international page, Google Translate can only do so much....