I don't think that's the issue - us date formats would only kick in with the named formats (i.e. "short"). Since he provided the format, the output should be a generic string in that format.
Mike, when I've had that issue I got around it by outputing the month with the abbreviation rather than the number e.g. 9 Jun 2010. Both ColdFusion and all the DBs I've worked with accept the format, and they have no need for best-guess interpretation. Blair On Wed, Jun 9, 2010 at 4:41 PM, Andrew Scott <andr...@andyscott.id.au>wrote: > Straight from the ColdFusion documentation Mike. > > Formats a date value using U.S. date formats. For international date > support, use > LSDateFormat<http://WSc3ff6d0ea77859461172e0811cbec22c24-6de1.html> > . > > > > On Wed, Jun 9, 2010 at 3:19 PM, Mike Kear <afpwebwo...@gmail.com> wrote: > >> I'm still testing, but it looks like at long last this problem is solved. >> For those who have been following this saga, the issue is that no matter >> what way I put the date into the code, it always seemed to be stored in the >> database in an erratic way. For dates earlier than the 13th of the month >> (and therefore ambiguous as to which is the day and which is the month in >> the date string) the database would store yyyy-dd-mm and for the 13th or >> later, it would store yyyy-mm-dd, which is what i wanted for all of the >> dates. >> >> It boiled down to a code generator that i've been using without any issues >> for a long time. The setter and getter for any date fields was like the >> following: >> >> >> =========================================================================================== >> <cffunction name="setTransDate" access="public" returntype="void" >> output="false"> >> <cfargument name="TransDate" type="string" required="true" /> >> <cfif isDate(arguments.TransDate)> >> <cfset arguments.TransDate = dateformat(arguments.TransDate,"DD/MM/YYYY") >> /> >> </cfif> >> <cfset variables.instance.TransDate = trim(arguments.TransDate) /> >> </cffunction> >> <cffunction name="getTransDate" access="public" returntype="string" >> output="false"> >> <cfreturn variables.instance.TransDate /> >> </cffunction> >> >> >> =========================================================================================== >> >> >> This date formatting was apparently what's causing the problem. I'm not >> sure why because I'd have thought it would either do nothing (i.e. convert >> dd/mm/yyyy into dd/mm/yyyy) or correct an American format date to Australian >> format date. >> >> But when i removed that manipulation, the problem went away. I'm a >> little nervous about just using it, because I think i should know why the >> former code was a problem but that will have to wait for another day. >> Here's the code that seems to give me the desired result: >> >> >> >> =========================================================================================== >> <cffunction name="setTransDate" access="public" returntype="void" >> output="false"> >> <cfargument name="TransDate" type="date" required="true" /> >> <cfset variables.instance.TransDate = arguments.TransDate /> >> </cffunction> >> <cffunction name="getTransDate" access="public" returntype="date" >> output="false"> >> <cfreturn variables.instance.TransDate /> >> </cffunction> >> >> >> =========================================================================================== >> >> I am MOST grateful to all those people - too numerous to mention now - who >> have helped me through this. Because it goes back to a code generator that >> I've never had any issues with while writing maybe 100 applications, I >> didn't even look at that. It was a LONG way down the list of possible >> suspects. I'll write and make sure Pete Farrell is in the loop on this. >> >> Thank you all. >> >> >> Cheers >> Mike Kear >> Windsor, NSW, Australia >> Adobe Certified Advanced ColdFusion Developer >> AFP Webworks >> http://afpwebworks.com >> ColdFusion 9 Enterprise, PHP, ASP, ASP.NET hosting from AUD$15/month >> >> -- >> You received this message because you are subscribed to the Google Groups >> "cfaussie" group. >> To post to this group, send email to cfaus...@googlegroups.com. >> To unsubscribe from this group, send email to >> cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/cfaussie?hl=en. >> > > -- > You received this message because you are subscribed to the Google Groups > "cfaussie" group. > To post to this group, send email to cfaus...@googlegroups.com. > To unsubscribe from this group, send email to > cfaussie+unsubscr...@googlegroups.com<cfaussie%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/cfaussie?hl=en. > -- You received this message because you are subscribed to the Google Groups "cfaussie" group. To post to this group, send email to cfaus...@googlegroups.com. To unsubscribe from this group, send email to cfaussie+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en.
