setLocale isn't server wide, not even application wide. It is request
based. If you want it app wide, you need to add it to
onRequestStart().
On Jan 7, 2008 12:07 AM, MrBuzzy [EMAIL PROTECTED] wrote:
I'd really like to keep this going but I'm confused about who is
talking to who :(
@Andrew
And in case it's of any value, if one felt that changing the locale
request-wide was still a problem (issuing setlocale in a given template to
affect a given function), note that one of the many hidden gems in CF8 is
that the LS functions now accept locale as an argument, so you don't even
need
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
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
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...?
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
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
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.
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
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,
@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
16 matches
Mail list logo
