We - I and my girlfriend. http://se.servik.com/fda/
Once upon a time we have solved to make the evening party and check
the action feminine viagra.
Have Bought the tablets, champaign and started to wait output.
http://se.servik.com/fda/
When has approached output - have collected the evening
I've been fighting an application (since 7:00am this morning) and it
turns out that is has a generous use of DateFormat() within it.
I'm quietly confident that replacing them with LSDateFormat() will
start it making sense again.
but the trouble there is how to add it into the app - pick up the
Very good question,
LS, or location / region settings was an added hack to get localisation
working. My view is that it is about time that this was all brought internal
to Coldfusion, so that we as developers make one setting either in the OS,
or Admin of CF and forget about it.
However it is
Retrofitting DataFormat to do what LSDateFormat does breaks
principle-of-least-surprise; Probably won't be too long before an angry
mob gathers.
That said, deprecating DateFormat sounds like a good idea, if for no
other reason but the fact that it makes your app easier to localise.
Andrew
My client is having problems adding products to their catalogue,
because whenever they use the double quote character to represent
inches, the database interprets that as the end of the field.
No problem, i'd have thought except when I do the same thing to
reproduce the problem, it doesnt occur.
How are the products being added? Coldfusion?
Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613 9015 8628
Mobile: 0404 998 273
-Original Message-
From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
Of Mike Kear
Sent: Monday, 7
Hi y'all, I'm not completely sure that this is a problem that needs to get
fixed... maybe I'm missing something...? Barry I'm definitely feeling your
pain on this one ;)
Dateformat will format dates in US format regardless of the
set/selected/configured/OS/JVM locale.
LSDateFormat will format
Ah, sorry Taco. I was focused on it more as a place to find tutorials, but
of course you were asking for a place to offer them. I do believe that the
CMX folks accept tutorials from new contributors. I've looked for a place to
propose them but find none, so have asked someone I know involved in it
you can override the OS settings with
SetLocale(new_locale)
eg, for Australia
SetLocale(English (Australian))
On Jan 7, 2008 12:32 PM, MrBuzzy [EMAIL PROTECTED] wrote:
Hi y'all, I'm not completely sure that this is a problem that needs to get
fixed... maybe I'm missing something...?
Are there any other differences with the server? Or maybe the browser?
The OS should not make a difference...
Andrew Scott
Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613 9015 8628
Mobile: 0404 998 273
-Original Message-
From: cfaussie@googlegroups.com
one thing to keep in mind is that dateformat has an always predictable
result (regardless of the locale),
where as LsDateFormat is not predictable due to it's dependancy on the
locale
Therefore it makes sense to have two functions and CF is always backwards
compatible, hence no deprectation
Well when i add a description like 42 wheels myself on the production
server, it stores in the database just fine. But when the client does
it, it doesn't. So there's something different about what the
client's doing.
The client's not what you'd call computer savvy, and isn't cutting and
Hi Mike,
I have found in the past a value such as 42 wheels is _inserted_ into
the database without any problem. However, when the update form is
used with the same value the html is rendered as:
input type=text name=myField value=42 wheels /
Notice that the value attribute is prematurely
how would you then parse a US date string to a date object without
setting your local to US?
hang on... what's wrong with U.S people setting their systems to a U.S
locale and using the LS functions? We have to (should) set our systems
to en_AU. Wot, some locales are more equal than others? (and
Hi all,
(IIS,SQL Server, CF7)
I am having been storing files as blobs successfully for a while and
am streaming it directly to the browser using the following:
CFHEADER NAME=content-disposition value=attachment;
filename=#fileDetails.file_name#
cfcontent type=#fileDetails.content_type#
hang on... what's wrong with U.S people setting their systems to a U.S
locale and using the LS functions? We have to (should) set our systems
to en_AU. Wot, some locales are more equal than others?
I wonder what % of people buying CF are in the US?
I know it's less the case then say a few
Sorry I'm not following.
Barry could you examplify your problem?
On 1/7/08, Barry Beattie [EMAIL PROTECTED] wrote:
how would you then parse a US date string to a date object without
setting your local to US?
hang on... what's wrong with U.S people setting their systems to a U.S
locale and
See below, but that is my point. The LS stuff is a fudge / hack and has
never been fully thought about, as I stated before, in my eyes localisation
should occur regardless of where the server is or not.
That is why DateFormat still exists, backwards compatability for older
coldfusion code.
Taco, as for submitting tutorials to the CommunityMX site as a non-partner
contributor, here's the info I got from my contact there:
As for guest authors, you can have him contact Bill Horvath,
[EMAIL PROTECTED] as he coordinates the outside authors. Frequently guest
authors articles are
Articulated much better than I could have.
Having had worked with apps where it's been assumed a (string
representation) of a date is a certain format (in most cases, NOT in the
app's native locale) has been a problem for me in the past. (The
problems stemmed from misconfigured databases and
Thanks Charlie, will give it a go.
On 1/7/08, Charlie Arehart (lists account) [EMAIL PROTECTED]
wrote:
Taco, as for submitting tutorials to the CommunityMX site as a
non-partner contributor, here's the info I got from my contact there:
As for guest authors, you can have him contact Bill
Thanks, Adam, i think you might have put your finger on it. If
you're right, it's not actually the DAO cfc or the database that's the
culprit, but the form stripping off the rest of the value in the input
field.
I've changed the form and asked the client to try it to see if the
problem goes
Mr Buzzy, the problem is nothing specific (the example I showed before
was incorrect).
I've just got an app that has code like this in quite a few places:
cfset value = dateFormat(value,mm/dd/yy)
instead of something like.
cfset value = LSDateFormat(value,short) /
or
cfset value =
D'oh!
depicted = deprecated
(bloody spell checkers)
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
cfaussie group.
To post to this group, send email to cfaussie@googlegroups.com
To unsubscribe from this group,
or, we could just make idiot American's use the same date formats as the rest
of the English-speaking world!
or is that too harsh (methinks not, having been burned by
Allaire/Macromedia/Adobe/Microsoft/Borland/the list goes on and on with regards
to storing, interpreting and using dates
@Barry so _value_ is a string or a date object?
Your examples seem valid on their own.
Again, if dateformat/parsedate was deprecated how would we Aussies
parse a us date string?
Time for a swim and a coopers lager :)
On 1/7/08, Barry Beattie [EMAIL PROTECTED] wrote:
D'oh!
depicted =
well, if ppl are wanting to sweat cycles on this
(sorry, maybe it's because of using strongly typed languages. I see
date handling as a very black and white issue. They're dates.
(actually dateTime) they always will be ... until people get
involved...)
@Barry so _value_ is a string or a
27 matches
Mail list logo
