On Tue, Jun 8, 2010 at 10:19 PM, Mike Kear <afpwebwo...@gmail.com> wrote:
> 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:

Storing dates as formatted strings is just asking for problems. I'm
glad you posted the set/get methods (as I asked) because now we can
see exactly why it fails!

> <cfset arguments.TransDate = dateformat(arguments.TransDate,"DD/MM/YYYY") />

So this converts a real date to a specific format string.

> <cfreturn variables.instance.TransDate />

And this returns the formatted string and it then gets converted to a
real date (when you go to the DB) using your native locale - which
*tries* to match it to an Australian date when it can but reverts to
the US format when it can't.

The moral is: never, ever store a date as a string :)

> <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>

That's how set/get methods should behave - no conversion.

BTW, it would be *really* useful to tell us which code generator you
used so we can avoid it...
-- 
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/

"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood

-- 
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.

Reply via email to