I think a few of you are missing what I am trying to say. I am still trying to confirm this 100%, but so far I have looked at the code and found that the code is in fact identical in both DateFormat() & LSDateFormat(). The only difference that I can see is that LSDateFormat has a wrapper to the main code to use local, then calles DateFormat().
So what I am saying is why was it done that way, the code cleary shows it setting DateFormat() with a default Locale of US. Like I stated I need to confirm it more, but that's what I see. I wasn't out for a war, a debate maybe. But wasn't trying to say DateFormat should be deprecated, instead of creating an extra function for LS[FunctionName] for localisation, why could they have checked the locale, and returned in that date. I mean as I stated the Code Clearly shows setting the locale to US and then calling the Java date functions passing the locale (Which is set to US). I know there must be a reason, but I just do not seem to see it. On 1/9/08, Barry Beattie <[EMAIL PROTECTED]> wrote: > > IMHO there are three "beasts" > > - undocumented functionality (and therefore unsupported) > - official features > - deprecated functionality. > > Just as "undocumented functionality" may evolve into "official > features", I see nothing wrong with moving stuff to be deprecated. Not > the same as dropping it completely (at least not yet). > > <cfcough> cfquery DSN querystrings anyone? </cfcough> > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
