[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 there for backwards compatability. But if it wasn't a hack in the first place, I do not think we would fall into this trap... And yes I still fall into this trap, even though I should know better. As for LSDateFormat working in the USA, it does as long as setLocale() is set to that region. 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 Barry Beattie Sent: Monday, 7 January 2008 11:24 AM To: cfaussie@googlegroups.com Subject: [cfaussie] should DateFormat() be depricated (in favour of LSDateFormat())? 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 locale in the setup ini file and if en_US then use dateFormat else use LSDateFormat? or just use LSDateFormat (relying on CF to get it right everywhere) and in the ini setup file, set the date display mask? and if the latter, is there a usecase for DateFormat() at all? I suppose I should ask this on a U.S list... I'm sure they're aware if LSDateFormat doesn't work for them just as we're acutely aware that DateFormat doesn't play nicely in out region. thoughts? comments? experiences? thanx barry.b --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 Scott wrote: > 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 there for backwards compatability. But if it wasn't a hack in > the first place, I do not think we would fall into this trap... > > And yes I still fall into this trap, even though I should know better. > > As for LSDateFormat working in the USA, it does as long as setLocale() is > set to that region. > > > > 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 Barry Beattie > Sent: Monday, 7 January 2008 11:24 AM > To: cfaussie@googlegroups.com > Subject: [cfaussie] should DateFormat() be depricated (in favour of > LSDateFormat())? > > > 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 > locale in the setup ini file and if en_US then use dateFormat else use > LSDateFormat? > > or just use LSDateFormat (relying on CF to get it right everywhere) > and in the ini setup file, set the date display mask? > > and if the latter, is there a usecase for DateFormat() at all? > > I suppose I should ask this on a U.S list... I'm sure they're aware if > LSDateFormat doesn't work for them just as we're acutely aware that > DateFormat doesn't play nicely in out region. > > thoughts? comments? experiences? > > thanx > barry.b > > > > > > > --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 (and parse) using the specified locale. Both will allow you to mask the output format in the same way, ie "dd mm " or "mm dd " IMO the difference (and cause of confusion in non US places) is two fold; 1. Often a non-US application could be hosted in the US or the server has the locale set to US when it shouldn't be. Some won't be aware of it - hence the "LS" parsing will be US anyhow. 2. DateFormat will parse strings to dates (as will DateParse). BUT when doing so it's too smart (or dumb) ... Dateformat will accept an input string like "29 01 2007" clearly this is not a US but DateFormat will parse correctly it because there is no ambiguity - IMO this scenarios should throw an error instead, it would help avoid problems. I don't think it can be deprecated. How would you then parse a US date string to a date object without setting your local to US? Perhaps another parse/format function that can be used by explicitly specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd yy","dd mm yy"). Barry, am I right to assume your problem was with dates as strings? Cheers. btw... I really am in a different world today - kicking back in Adelaide with a beach view nice ;) On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: > > 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 Scott wrote: > > 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 there for backwards compatability. But if it wasn't a hack > in > > the first place, I do not think we would fall into this trap... > > > > And yes I still fall into this trap, even though I should know better. > > > > As for LSDateFormat working in the USA, it does as long as setLocale() > is > > set to that region. > > > > > > > > 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 Barry Beattie > > Sent: Monday, 7 January 2008 11:24 AM > > To: cfaussie@googlegroups.com > > Subject: [cfaussie] should DateFormat() be depricated (in favour of > > LSDateFormat())? > > > > > > 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 > > locale in the setup ini file and if en_US then use dateFormat else use > > LSDateFormat? > > > > or just use LSDateFormat (relying on CF to get it right everywhere) > > and in the ini setup file, set the date display mask? > > > > and if the latter, is there a usecase for DateFormat() at all? > > > > I suppose I should ask this on a U.S list... I'm sure they're aware if > > LSDateFormat doesn't work for them just as we're acutely aware that > > DateFormat doesn't play nicely in out region. > > > > thoughts? comments? experiences? > > > > thanx > > barry.b > > > > > > > > > > > > > > > > > > --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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...? 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 (and parse) using the specified locale.
>
> Both will allow you to mask the output format in the same way, ie "dd mm
> " or "mm dd "
>
> IMO the difference (and cause of confusion in non US places) is two fold;
> 1. Often a non-US application could be hosted in the US or the server
> has the locale set to US when it shouldn't be. Some won't be aware of it -
> hence the "LS" parsing will be US anyhow.
> 2. DateFormat will parse strings to dates (as will DateParse). BUT when
> doing so it's too smart (or dumb) ... Dateformat will accept an input string
> like "29 01 2007" clearly this is not a US but DateFormat will parse
> correctly it because there is no ambiguity - IMO this scenarios should throw
> an error instead, it would help avoid problems.
>
> I don't think it can be deprecated. How would you then parse a US date
> string to a date object without setting your local to US?
> Perhaps another parse/format function that can be used by explicitly
> specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd
> yy","dd mm yy").
>
> Barry, am I right to assume your problem was with dates as strings?
>
> Cheers.
>
> btw... I really am in a different world today - kicking back in Adelaide
> with a beach view nice ;)
>
>
> On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote:
>
> >
> > 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 Scott wrote:
> > > 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 there for backwards compatability. But if it wasn't a
> > hack in
> > > the first place, I do not think we would fall into this trap...
> > >
> > > And yes I still fall into this trap, even though I should know better.
> >
> > >
> > > As for LSDateFormat working in the USA, it does as long as setLocale()
> > is
> > > set to that region.
> > >
> > >
> > >
> > > 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 Barry Beattie
> > > Sent: Monday, 7 January 2008 11:24 AM
> > > To: cfaussie@googlegroups.com
> > > Subject: [cfaussie] should DateFormat() be depricated (in favour of
> > > LSDateFormat())?
> > >
> > >
> > > 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
> > > locale in the setup ini file and if en_US then use dateFormat else use
> > > LSDateFormat?
> > >
> > > or just use LSDateFormat (relying on CF to get it right everywhere)
> > > and in the ini setup file, set the date display mask?
> > >
> > > and if the latter, is there a usecase for DateFormat() at all?
> > >
> > > I suppose I should ask this on a U.S list... I'm sure they're aware if
> > > LSDateFormat doesn't work for them just as we're acutely aware that
> > > DateFormat doesn't play nicely in out region.
> > >
> > > thoughts? comments? experiences?
> > >
> > > thanx
> > > barry.b
> > >
> > >
> > >
> > > >
> > >
> > >
> >
> > > >
> >
--
AJ Mercer
Web Log: http://webonix.net
--~--~-~--~~~---~--~~
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, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/cfaussie?hl=en
-~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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
z
On Jan 7, 2008 3:01 PM, AJ Mercer <[EMAIL PROTECTED]> wrote:
> 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...? 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 (and parse) using the specified locale.
> >
> > Both will allow you to mask the output format in the same way, ie "dd mm
> > " or "mm dd "
> >
> > IMO the difference (and cause of confusion in non US places) is two
> > fold;
> > 1. Often a non-US application could be hosted in the US or the server
> > has the locale set to US when it shouldn't be. Some won't be aware of it -
> > hence the "LS" parsing will be US anyhow.
> > 2. DateFormat will parse strings to dates (as will DateParse). BUT
> > when doing so it's too smart (or dumb) ... Dateformat will accept an input
> > string like "29 01 2007" clearly this is not a US but DateFormat will parse
> > correctly it because there is no ambiguity - IMO this scenarios should throw
> > an error instead, it would help avoid problems.
> >
> > I don't think it can be deprecated. How would you then parse a US date
> > string to a date object without setting your local to US?
> > Perhaps another parse/format function that can be used by explicitly
> > specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd
> > yy","dd mm yy").
> >
> > Barry, am I right to assume your problem was with dates as strings?
> >
> > Cheers.
> >
> > btw... I really am in a different world today - kicking back in Adelaide
> > with a beach view nice ;)
> >
> >
> > On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote:
> >
> > >
> > > 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 Scott wrote:
> > > > 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 there for backwards compatability. But if it wasn't a
> > > hack in
> > > > the first place, I do not think we would fall into this trap...
> > > >
> > > > And yes I still fall into this trap, even though I should know
> > > better.
> > > >
> > > > As for LSDateFormat working in the USA, it does as long as
> > > setLocale() is
> > > > set to that region.
> > > >
> > > >
> > > >
> > > > 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 Barry Beattie
> > > > Sent: Monday, 7 January 2008 11:24 AM
> > > > To: cfaussie@googlegroups.com
> > > > Subject: [cfaussie] should DateFormat() be depricated (in favour of
> > > > LSDateFormat())?
> > > >
> > > >
> > > > 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
> > > > locale in the setup ini file and if en_US then use dateFormat else
> > > use
> > > > LSDateFormat?
> > > >
> > > > or just use LSDateFormat (relying on CF to get it right everywhere)
> > > > and in the ini setup file, set the date display mask?
> > > >
> > > > and if the latter, is there a usecase for DateFormat() at all?
> > > >
> > > > I suppose I should ask this on a U.S list... I'm sure they're aware
> > > if
> > > > LSDateFormat doesn't work for them just as we're acutely aware that
> > > > DateFormat doesn't play nicely in out region.
> > > >
> > > > thoughts? comments? experiences?
> > > >
> > > > thanx
> > > > barry.b
> > > >
> > > >
> > > >
> > > > >
> > > >
> > > >
> > >
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
"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 if the server is wrong, then re-ssetting the locale as Andrew suggests is the fix, not an if DateFormat else LSDateFormat) "where as LsDateFormat is not predictable due to it's dependancy on the locale" IMHO, that's not a problem. Set your locale up correctly and you should get just the results you want. The app's moving to a different locale? change that, not the code/conversions/hacks. 2008-01-04 16:18:00.000 is the 1st of April with DateFormat or (correctly) 4th of Jan with LSDateFormat... the core data (in the database) is agnostic - just the way it should be. your application formats it "just so", depending on what you set-up for your region (a la workstation operating systems and MSWord, etc). If all the LS functions work perfectly well after setting the locale - no matter what locale it is - then why have the older versions at all? It's a shame when i18n becomes an afterthought and you get burnt by needing to retrofit it. if what people are saying is that LSDateFormat is broken in "en_US" locales then that's what needs to be said. A generic fix in the hand is worth more than two hacks in the bush. eh my 2c barry.b On Jan 7, 2008 1: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...? 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 (and parse) using the specified locale. > > Both will allow you to mask the output format in the same way, ie "dd mm > " or "mm dd " > > IMO the difference (and cause of confusion in non US places) is two fold; > 1. Often a non-US application could be hosted in the US or the server has > the locale set to US when it shouldn't be. Some won't be aware of it - hence > the "LS" parsing will be US anyhow. > 2. DateFormat will parse strings to dates (as will DateParse). BUT when > doing so it's too smart (or dumb) ... Dateformat will accept an input string > like "29 01 2007" clearly this is not a US but DateFormat will parse > correctly it because there is no ambiguity - IMO this scenarios should throw > an error instead, it would help avoid problems. > > I don't think it can be deprecated. How would you then parse a US date > string to a date object without setting your local to US? > Perhaps another parse/format function that can be used by explicitly > specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd > yy","dd mm yy"). > > Barry, am I right to assume your problem was with dates as strings? > > Cheers. > > btw... I really am in a different world today - kicking back in Adelaide > with a beach view nice ;) > > > > On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: > > > > 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 Scott wrote: > > > 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 there for backwards compatability. But if it wasn't a hack > in > > > the first place, I do not think we would fall into this trap... > > > > > > And yes I still fall into this trap, even though I should know better. > > > > > > As for LSDateFormat working in the USA, it does as long as setLocale() > is > > > set to that region. > > > > > > > > > > > > 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 Barry Beattie > > > Sent: Monday, 7 January 2008 11:24 AM > > > To: cfaussie@googlegroups.com > > > Subject: [cfaussie] should DateFormat() be depricated (in favour of > > > LSDateFormat())? > > > > > > > > > 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
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
> 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 years ago - but I was once told by a software vendor that 'catering for foriegn date formats isn't worth the effort' and that I should 'suck it up and just use US date formatting'. I would note that the vendor has since been bought out by microsoft after having been a leader in their field for years while refusing to support alternate date formats. My experience has almost universally been that developer tools were developed first and foremost for the US market and internationalization was always an afterthought hacked together at the last minute. Or that some locates are absolutely more equal than others in development practice if not in the PR material. > (and if the > server is wrong, then re-ssetting the locale as Andrew suggests is the > fix, not an if DateFormat else LSDateFormat) > > "where as LsDateFormat is not predictable due to it's dependancy on > the locale" > > IMHO, that's not a problem. Set your locale up correctly and you > should get just the results you want. The app's moving to a different > locale? change that, not the code/conversions/hacks. > > 2008-01-04 16:18:00.000 is the 1st of April with DateFormat or > (correctly) 4th of Jan with LSDateFormat... the core data (in the > database) is agnostic - just the way it should be. your application > formats it "just so", depending on what you set-up for your region (a > la workstation operating systems and MSWord, etc). > > If all the LS functions work perfectly well after setting the locale - > no matter what locale it is - then why have the older versions at all? > It's a shame when i18n becomes an afterthought and you get burnt by > needing to retrofit it. > > if what people are saying is that LSDateFormat is broken in "en_US" > locales then that's what needs to be said. A generic fix in the hand > is worth more than two hacks in the bush. > > eh my 2c > barry.b > > > > > > > On Jan 7, 2008 1: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...? 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 (and parse) using the specified locale. >> >> Both will allow you to mask the output format in the same way, ie "dd mm >> " or "mm dd " >> >> IMO the difference (and cause of confusion in non US places) is two fold; >> 1. Often a non-US application could be hosted in the US or the server has >> the locale set to US when it shouldn't be. Some won't be aware of it - hence >> the "LS" parsing will be US anyhow. >> 2. DateFormat will parse strings to dates (as will DateParse). BUT when >> doing so it's too smart (or dumb) ... Dateformat will accept an input string >> like "29 01 2007" clearly this is not a US but DateFormat will parse >> correctly it because there is no ambiguity - IMO this scenarios should throw >> an error instead, it would help avoid problems. >> >> I don't think it can be deprecated. How would you then parse a US date >> string to a date object without setting your local to US? >> Perhaps another parse/format function that can be used by explicitly >> specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd >> yy","dd mm yy"). >> >> Barry, am I right to assume your problem was with dates as strings? >> >> Cheers. >> >> btw... I really am in a different world today - kicking back in Adelaide >> with a beach view nice ;) >> >> >> >> On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: >> >>> 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 Scott wrote: >>> 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 there for backwards compatability. But if it wasn't a hack >> in >> the first place, I do not think we would fall into this trap... And yes I still fall into this trap, even though I should know better. As for LSDateFormat working in the USA, it does as long as s
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 using the LS functions? We have to (should) set our systems > to en_AU. Wot, some locales are more equal than others? (and if the > server is wrong, then re-ssetting the locale as Andrew suggests is the > fix, not an if DateFormat else LSDateFormat) > > "where as LsDateFormat is not predictable due to it's dependancy on > the locale" > > IMHO, that's not a problem. Set your locale up correctly and you > should get just the results you want. The app's moving to a different > locale? change that, not the code/conversions/hacks. > > 2008-01-04 16:18:00.000 is the 1st of April with DateFormat or > (correctly) 4th of Jan with LSDateFormat... the core data (in the > database) is agnostic - just the way it should be. your application > formats it "just so", depending on what you set-up for your region (a > la workstation operating systems and MSWord, etc). > > If all the LS functions work perfectly well after setting the locale - > no matter what locale it is - then why have the older versions at all? > It's a shame when i18n becomes an afterthought and you get burnt by > needing to retrofit it. > > if what people are saying is that LSDateFormat is broken in "en_US" > locales then that's what needs to be said. A generic fix in the hand > is worth more than two hacks in the bush. > > eh my 2c > barry.b > > > > > > > On Jan 7, 2008 1: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...? 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 (and parse) using the specified locale. > > > > Both will allow you to mask the output format in the same way, ie "dd mm > > " or "mm dd " > > > > IMO the difference (and cause of confusion in non US places) is two fold; > > 1. Often a non-US application could be hosted in the US or the server > has > > the locale set to US when it shouldn't be. Some won't be aware of it - > hence > > the "LS" parsing will be US anyhow. > > 2. DateFormat will parse strings to dates (as will DateParse). BUT when > > doing so it's too smart (or dumb) ... Dateformat will accept an input > string > > like "29 01 2007" clearly this is not a US but DateFormat will parse > > correctly it because there is no ambiguity - IMO this scenarios should > throw > > an error instead, it would help avoid problems. > > > > I don't think it can be deprecated. How would you then parse a US date > > string to a date object without setting your local to US? > > Perhaps another parse/format function that can be used by explicitly > > specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd > > yy","dd mm yy"). > > > > Barry, am I right to assume your problem was with dates as strings? > > > > Cheers. > > > > btw... I really am in a different world today - kicking back in Adelaide > > with a beach view nice ;) > > > > > > > > On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: > > > > > > 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 Scott wrote: > > > > 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 there for backwards compatability. But if it wasn't a > hack > > in > > > > the first place, I do not think we would fall into this trap... > > > > > > > > And yes I still fall into this trap, even though I should know better. > > > > > > > > As for LSDateFormat working in the USA, it does as long as setLocale() > > is > > > > set to that region. > > > > > > > > > > > > > > > > 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 Barry Beattie > > > > Sent: Monday, 7 January 2008 11:24 AM > > > > To: cfaussie@googlegroups.com > > > > Subject: [cfaussie] shoul
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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. 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 Barry Beattie Sent: Monday, 7 January 2008 4:08 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())? "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 if the server is wrong, then re-ssetting the locale as Andrew suggests is the fix, not an if DateFormat else LSDateFormat) --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 servers but never-you-mind. When people accept bad behaviour, it causes more headaches further still). (Before anyone says anything, people who store string representations of dates should be drawn and quartered.) Also, don't forget that allowing users to pick their own locale and timezone is not only good practice, but practically expected in this day and age... Barry Beattie 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 using the LS functions? We have to (should) set our systems > to en_AU. Wot, some locales are more equal than others? (and if the > server is wrong, then re-ssetting the locale as Andrew suggests is the > fix, not an if DateFormat else LSDateFormat) > > "where as LsDateFormat is not predictable due to it's dependancy on > the locale" > > IMHO, that's not a problem. Set your locale up correctly and you > should get just the results you want. The app's moving to a different > locale? change that, not the code/conversions/hacks. > > 2008-01-04 16:18:00.000 is the 1st of April with DateFormat or > (correctly) 4th of Jan with LSDateFormat... the core data (in the > database) is agnostic - just the way it should be. your application > formats it "just so", depending on what you set-up for your region (a > la workstation operating systems and MSWord, etc). > > If all the LS functions work perfectly well after setting the locale - > no matter what locale it is - then why have the older versions at all? > It's a shame when i18n becomes an afterthought and you get burnt by > needing to retrofit it. > > if what people are saying is that LSDateFormat is broken in "en_US" > locales then that's what needs to be said. A generic fix in the hand > is worth more than two hacks in the bush. > > eh my 2c > barry.b > > > > > > > On Jan 7, 2008 1: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...? 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 (and parse) using the specified locale. >> >> Both will allow you to mask the output format in the same way, ie "dd mm >> " or "mm dd " >> >> IMO the difference (and cause of confusion in non US places) is two fold; >> 1. Often a non-US application could be hosted in the US or the server has >> the locale set to US when it shouldn't be. Some won't be aware of it - hence >> the "LS" parsing will be US anyhow. >> 2. DateFormat will parse strings to dates (as will DateParse). BUT when >> doing so it's too smart (or dumb) ... Dateformat will accept an input string >> like "29 01 2007" clearly this is not a US but DateFormat will parse >> correctly it because there is no ambiguity - IMO this scenarios should throw >> an error instead, it would help avoid problems. >> >> I don't think it can be deprecated. How would you then parse a US date >> string to a date object without setting your local to US? >> Perhaps another parse/format function that can be used by explicitly >> specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd >> yy","dd mm yy"). >> >> Barry, am I right to assume your problem was with dates as strings? >> >> Cheers. >> >> btw... I really am in a different world today - kicking back in Adelaide >> with a beach view nice ;) >> >> >> >> On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: >> >>> 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 Scott wrote: >>> 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 there for backwards compatability. But if it wasn't a hack >> in >> the first place, I do not think we would fall into this trap... And yes I still fall into this trap, even though I should know better. As for LSDateFormat working in the U
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
I'd really like to keep this going but I'm confused about who is talking to who :( @Andrew I don't agree it's a hack, I could accept that it's a necessary evil. @hakal I totally agree that date strings are evil and probably at the heart of the problems. Someone mentioned using setlocale()... Feel free to correct me, but isn't that a server wide function? Changing the locale this way *could* cause problems to other apps. It'd be nice if it was an application property instead. On 1/7/08, Haikal Saadh <[EMAIL PROTECTED]> wrote: > > 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 servers but > never-you-mind. When people accept bad behaviour, it causes more > headaches further still). > > (Before anyone says anything, people who store string representations of > dates should be drawn and quartered.) > > Also, don't forget that allowing users to pick their own locale and > timezone is not only good practice, but practically expected in this day > and age... > > > > Barry Beattie 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 using the LS functions? We have to (should) set our systems > > to en_AU. Wot, some locales are more equal than others? (and if the > > server is wrong, then re-ssetting the locale as Andrew suggests is the > > fix, not an if DateFormat else LSDateFormat) > > > > "where as LsDateFormat is not predictable due to it's dependancy on > > the locale" > > > > IMHO, that's not a problem. Set your locale up correctly and you > > should get just the results you want. The app's moving to a different > > locale? change that, not the code/conversions/hacks. > > > > 2008-01-04 16:18:00.000 is the 1st of April with DateFormat or > > (correctly) 4th of Jan with LSDateFormat... the core data (in the > > database) is agnostic - just the way it should be. your application > > formats it "just so", depending on what you set-up for your region (a > > la workstation operating systems and MSWord, etc). > > > > If all the LS functions work perfectly well after setting the locale - > > no matter what locale it is - then why have the older versions at all? > > It's a shame when i18n becomes an afterthought and you get burnt by > > needing to retrofit it. > > > > if what people are saying is that LSDateFormat is broken in "en_US" > > locales then that's what needs to be said. A generic fix in the hand > > is worth more than two hacks in the bush. > > > > eh my 2c > > barry.b > > > > > > > > > > > > > > On Jan 7, 2008 1: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...? 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 (and parse) using the specified locale. > >> > >> Both will allow you to mask the output format in the same way, ie "dd mm > >> " or "mm dd " > >> > >> IMO the difference (and cause of confusion in non US places) is two fold; > >> 1. Often a non-US application could be hosted in the US or the server > has > >> the locale set to US when it shouldn't be. Some won't be aware of it - > hence > >> the "LS" parsing will be US anyhow. > >> 2. DateFormat will parse strings to dates (as will DateParse). BUT when > >> doing so it's too smart (or dumb) ... Dateformat will accept an input > string > >> like "29 01 2007" clearly this is not a US but DateFormat will parse > >> correctly it because there is no ambiguity - IMO this scenarios should > throw > >> an error instead, it would help avoid problems. > >> > >> I don't think it can be deprecated. How would you then parse a US date > >> string to a date object without setting your local to US? > >> Perhaps another parse/format function that can be used by explicitly > >> specifying the input at output masks. ie; DateStringFormat(strDate,"mm dd > >> yy","dd mm yy"). > >> > >> Barry, am I right to assume your problem was with dates as strings? > >> > >> Cheers. > >> > >> btw... I really am in a different world today - kicking back in Adelaide > >> with a beach view nice ;) > >> > >> > >> > >> On Jan 7, 2008 11:42 AM, Haikal Saadh <[EMAIL PROTECTED]> wrote: > >> > >>> 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 e
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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: instead of something like. or the original codebase has a bit of history so this sort of thing is understandable. The next version probably has it all cleaned up. but that got me thinking, why are there two ways of doing the same thing, leaving the door open to perpetuate old bad habits or unnecessary hacks? - and - is there anything wrong with keeping i18n first and foremost in what we do and how we do it? everyone keeps saying that dateFormat() is for backward compatibility. Isn't that admitting that it's as good as depicted anyway? why not make it official and weed it out of existence in support for all the LS series of functions? if the LS functions aren't robust and can't be trusted in all cases, then the answer is to make sure they work right. And if they do work, then that's all we should need. "Also, don't forget that allowing users to pick their own locale and timezone is not only good practice, but practically expected in this day and age..." here here! --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
@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" = 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 date object? in that case, for display. IMHO, all dates should be kept as date objects until they are needed for display - and all strings representing dates (eg from calendar UI widgets) converted to date objects as soon as possible. Date comparisons, dateadd, etc done with date objects. Only when they are strings do they get converted treated as such (user input, display). (doesn't anyone like LSParseDate?) > Your examples seem valid on their own. except that the mask is assuming I want the date displayed in U.S format and is hard coded (but that's another issue) > Again, if dateformat/parsedate was deprecated how would we Aussies > parse a us date string? is the string directly from user input - or - for display? you'd have to ask yourself why it's a "US date" string and not a "string representing a date from a user in the U.S locale..". The difference is context: the format is not "owned" by the string but by the user while using the application. Sure I'm playing with semantics but It's only a bunch of symbols after all, not a date, and as such only has meaning for humans because we think it looks like a date. Internally it should be a date object so the system can user it (correctly). you've got a U.S user on an Australian webapp/website looking at data and he wants to see it displayed (or enter it) like "back home"? Sniff him out, find his locale preference and set that. just for him. Make him feel special. Failing that, he's using an Australian webapp and "he'd bloody well better get used to the way we do it around here, mate!" (in other words, you know he'd entered a bodgy date in mm/dd/ format - convert it to the real thing as fast as possible - or better still give him a date picker so he can't stuff it up). what I'm getting at is that the only thing that changes is how the user wants to interact with the data, not the data itself. It's still a date under the hood. eh. my 2c. > Time for a swim and a coopers lager :) > > On 1/7/08, Barry Beattie <[EMAIL PROTECTED]> wrote: > > > > > 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 I don't agree it's a hack, I could accept that it's a necessary evil. > > @hakal I totally agree that date strings are evil and probably at the > heart of the problems. > > Someone mentioned using setlocale()... Feel free to correct me, but > isn't that a server wide function? Changing the locale this way > *could* cause problems to other apps. It'd be nice if it was an > application property instead. > -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
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 to use setLocale if you don't want to for some reason. (It also helps for the situation where SetLocale doesn't work after a CFFLUSH, etc.) For those curious, yes I did mention this in my Hidden Gems talk, but many surely have not seen it, and even those who did might have forgotten it. :-) /charlie -Original Message- From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Raymond Camden Sent: Monday, January 07, 2008 12:15 PM To: cfaussie@googlegroups.com Subject: [cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())? 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 I don't agree it's a hack, I could accept that it's a necessary evil. > > @hakal I totally agree that date strings are evil and probably at the > heart of the problems. > > Someone mentioned using setlocale()... Feel free to correct me, but > isn't that a server wide function? Changing the locale this way > *could* cause problems to other apps. It'd be nice if it was an > application property instead. > -- === Raymond Camden, Camden Media Email: [EMAIL PROTECTED] Blog : www.coldfusionjedi.com AOL IM : cfjedimaster Keep up to date with the community: http://www.coldfusionbloggers.org --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
[cfaussie] Re: should DateFormat() be depricated (in favour of LSDateFormat())?
Ray/Charlie thanks for clarifying the setlocale behavior. For the record i don't have any problem using any of the local functions and I think they should stay as is. On 1/8/08, Charlie Arehart (lists account) <[EMAIL PROTECTED]> wrote: > > 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 to use setLocale if you don't want to for some reason. (It also helps > for the situation where SetLocale doesn't work after a CFFLUSH, etc.) > > For those curious, yes I did mention this in my Hidden Gems talk, but many > surely have not seen it, and even those who did might have forgotten it. :-) > > /charlie > > -Original Message- > From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf > Of Raymond Camden > Sent: Monday, January 07, 2008 12:15 PM > To: cfaussie@googlegroups.com > Subject: [cfaussie] Re: should DateFormat() be depricated (in favour of > LSDateFormat())? > > > 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 I don't agree it's a hack, I could accept that it's a necessary > evil. > > > > @hakal I totally agree that date strings are evil and probably at the > > heart of the problems. > > > > Someone mentioned using setlocale()... Feel free to correct me, but > > isn't that a server wide function? Changing the locale this way > > *could* cause problems to other apps. It'd be nice if it was an > > application property instead. > > > > -- > === > Raymond Camden, Camden Media > > Email: [EMAIL PROTECTED] > Blog : www.coldfusionjedi.com > AOL IM : cfjedimaster > > Keep up to date with the community: http://www.coldfusionbloggers.org > > > > > > > --~--~-~--~~~---~--~~ 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, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/cfaussie?hl=en -~--~~~~--~~--~--~---
