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 > > yyyy" or "mm dd yyyy" > > > > 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 niiiiice ;) > > > > > > > > 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 -~----------~----~----~----~------~----~------~--~---
