Lauren's solution is good. The formatting string for the FormatDate
function is documented in the FusionPro Rules System Guide.
But there's a problem here. If you actually try Lauren's code with the
data from Richard's example (11/04/2008), it doesn't give the result
that he said he was looking for (11 April, 2008). Instead, it returns
"04 November, 2008".
The problem is, if you have a string representing a date such as
"11/04/2008", does that mean April 11th or November 4th? Most people in
the U.S. would say November 4th, while in Europe, that would represent
April 11th. This kind of representation is inherently ambiguous.
There's no "right" answer.
Now, FusionPro's FormatDate and DateFromString functions use
JavaScript's core Date.parse method internally. Such JavaScript methods
are generally locale-aware, so you should get the "right" results
depending on your operating system and other aspects of your runtime
environment, such as what locale and time zone your system clock is set
for. In other words, if you're in the U.S., it should parse as
"mm/dd/yyyy", and if you're in Europe, it should parse as "dd/mm/yyyy".
But you probably don't really want your job to compose differently on
the computer of a customer who's overseas than it does for you. Plus,
the system locale may be unreliable anyway, especially on the Mac, where
FusionPro Server runs under the locale-oblivious Carbon CFM runtime.
But that's a whole 'nother show.
Therefore, you really don't want to pass strings with just numbers and
slashes to these date-parsing functions, because that kind of ambiguity
is trouble waiting to happen.
So, if you want to make sure you always get the right result, you need
to parse the date string to be more explicit about exactly what day,
month, and year it's specifying. For instance:
var MyDateAsString = "11/04/2008"; // Field("MyDate");
// Parse string as "dd/mm/yyyy".
var DateParts = MyDateAsString.split("/");
if (DateParts.length != 3)
return "Invalid date specification: " + MyDateAsString;
var MyDateDay = DateParts[0];
var MyDateMonth = DateParts[1];
var MyDateYear = DateParts[2];
var MyDate = new Date(MyDateYear, MyDateMonth-1, MyDateDay);
return FormatDate(MyDate, "d lm, yyyy");
Note that if you wanted to parse the date in the U.S. style of
"mm/dd/yyyy" instead, you could just switch around the MyDateDay and
MyDateMonth variables and the substrings they're pointing to. Also note
that using a single "d" in the formatting string instead of "dd" strips
off any leading zeros, so that you get "4" instead of "04".
The moral of the story is that it's always better to be more explicit
and specific with the components of dates, whether it's specifying four
digits for the year, or explicitly setting the month and date as
separate parameters, rather than relying on some code to parse things
out for you. Of course, the best thing is to start out with
unambiguous, explicit data, such as a database with separate fields for
the day, month, and year, or with a date-specific data type such as an
SQL_DATETIME field in a database, but I realize that you have to deal
with what the customer gives you. But I feel compelled to once again
remind everyone to be wary of making assumptions about the data,
especially if it comes from a third party, and even more especially if
it's not very specific about what its type or format is. Again, the
mantra is: Know Thy Data.
Imagine if, say, a bank used just numeric representations of dates such
as "11/04/2008" and miscalculated a payment date because they were
assuming a European-type specification but it was actually a U.S.-type
specification; millions of dollars could be lost. So, serious
enterprise-level business applications can't afford to be ambiguous with
their data in any way.
(Of course, the most famous example of an ambiguity in date
representations was the Y2K bug, but you're at least using four digits
for the year here. Similarly, the Mars Global Surveyor project was lost
because someone at NASA misinterpreted a metric value in some data from
a European subcontractor as an English value, as in feet and pounds
rather than meters and kilograms.)
I hope this was helpful. Let me know if you want any more explanation
of date representations.
Dan
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
FusionPro 5.0 Now Available!
Variable text on a curve and soft drop-shadows for variable text
LIMITED TIME upgrade offer of $299 per license for current customers:
http://fusionpro.printable.com/store/upgrade
New licenses available for $599 each at:
http://fusionpro.printable.com/store/
All FusionPro 5.0 customers to receive FusionPro 5.1 with
Adobe Acrobat 8 and InDesign CS3 support when released for FREE.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
--
Users of FusionPro Desktop have unlimited free email support. Contact Printable
Support at [EMAIL PROTECTED]
--
View FusionPro Knowledge Base, FusionPro Samples at
www.printable.com/vdp/desktop.htm
--
You are currently subscribed to fusionpro as: [EMAIL PROTECTED]
To unsubscribe send a blank email to [EMAIL PROTECTED]
--
--
Note: All e-mail sent to or from this address will be received or otherwise
recorded by the e-mail recipients of this forum. It is subject to archival,
monitoring or review by, and/or disclosure to someone other than the recipient.
Our privacy policy is posted on www.printplanet.com
--
