Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Barry Beattie]

> string to date conversion as soon as form data is read. LSDateFormat()
> and other tools are part of a "form processing" layer before it gets

FUKIT!

dateFormat was for display. One of the Parse()/isDate() functions was
used for conversion/replace with sentinal values. I can't remember
what it was now.

I really must learn to shut the F up while I'm still this broken. No Fun.

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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Barry Beattie]

Gareth (QLD CFUG mgr) and I identified this (dates as strings) as a
problem when developing a custom framework right back in CF6.1 days.

For my money, the only way to handle this is to strongly type all the
data as it moves from one layer to another (inc the DB), starting the
string to date conversion as soon as form data is read. LSDateFormat()
and other tools are part of a "form processing" layer before it gets
placed in it's first object/CFC. We thought of it as the opposite side
to formatting strongly typed data to strings for display (eg: decimals
as currency, etc).

The only downside to that is optional date values. This means picking
up an empty string from the form and replacing it with a sentinal
value (eg 1/1/0001) at the "form processing" layer with a
corrosponding piece of logic to convert that to a DBNULL.

IMHO the same holds true for numbers, especially decimals. That's one
of the many things I like Mark doing with Transfer - he thought of
this problem and tried to address it.

at least this is what my shattered mind can remember...

barry.b





uh oh. I can see a "CF needs NULL's" argument happening ... again ...

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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Mike Kear]

I have no problem with posting the name of code generator, but let me share
this with the author first.   Then I'll post more details.

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




On Wed, Jun 9, 2010 at 5:40 PM, Sean Corfield wrote:

[snippety snip]


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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Blair McKenzie]

Good point. It only becomes an issue when the date has to be a string at
some point, e.g. form fields.

On 09/06/2010 5:40 PM, "Sean Corfield"  wrote:

On Tue, Jun 8, 2010 at 10:19 PM, Mike Kear  wrote:
> It boiled down to a code...
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!


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

> 

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


>  output="false">
> 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 ...

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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Sean Corfield]

On Tue, Jun 8, 2010 at 10:19 PM, Mike Kear  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!

> 

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

> 

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

>  output="false">
> 
> 
> 
>  output="false">
> 
> 

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.

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Zac Spitzer]

+1 on using the three letter month... almost impossible to confuse and
human friendly to boot

On 9 June 2010 16:49, Blair McKenzie  wrote:
> 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 
> wrote:
>>
>> Straight from the ColdFusion documentation Mike.
>>
>> Formats a date value using U.S. date formats. For international date
>> support, use LSDateFormat.
>>
>>
>> On Wed, Jun 9, 2010 at 3:19 PM, Mike Kear  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 -dd-mm  and for the 13th or
>>> later, it would store -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:
>>>
>>>  ===
>>> >> output="false">
>>> 
>>> 
>>> >> />
>>> 
>>> 
>>> 
>>> >> output="false">
>>> 
>>> 
>>>
>>>  ===
>>>
>>> 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/ into dd/mm/) 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:
>>>
>>>  ===
>>> >> output="false">
>>> 
>>> 
>>> 
>>> >> output="false">
>>> 
>>> 
>>>
>>>  ===
>>> 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.
>>> 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.
>
> --
> 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.
>



-- 
Zac Spitzer
Solution Architect / Director
Ennoble Consultancy Australia
http://www.ennoble.com.au
http://zacster.blogspot.com
+61 405 847 168

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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Blair McKenzie]

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

> Straight from the ColdFusion documentation Mike.
>
> Formats a date value using U.S. date formats. For international date
> support, use 
> LSDateFormat
> .
>
>
>
> On Wed, Jun 9, 2010 at 3:19 PM, Mike Kear  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 -dd-mm  and for the 13th or
>> later, it would store -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:
>>
>>  
>> ===
>> > output="false">
>> 
>>  
>> > />
>>  
>> 
>> 
>> > output="false">
>> 
>> 
>>
>>  
>> ===
>>
>>
>> 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/ into dd/mm/) 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:
>>
>>
>>  
>> ===
>> > output="false">
>>  
>> 
>> 
>> > output="false">
>> 
>> 
>>
>>  
>> ===
>>
>> 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
>> .
>> 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.
>

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

Re: [cfaussie] The solution: Odd date behaviour - CF9/SQLServer2005

[Andrew Scott]

Straight from the ColdFusion documentation Mike.

Formats a date value using U.S. date formats. For international date
support, use LSDateFormat .


On Wed, Jun 9, 2010 at 3:19 PM, Mike Kear  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 -dd-mm  and for the 13th or
> later, it would store -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:
>
>  
> ===
>  output="false">
> 
>  
>  />
>  
> 
> 
>  output="false">
> 
> 
>
>  
> ===
>
>
> 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/ into dd/mm/) 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:
>
>
>  
> ===
>  output="false">
>  
> 
> 
>  output="false">
> 
> 
>
>  
> ===
>
> 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
> .
> 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.