On Saturday, April 9, 2005, at 11:39 AM, Alain Pastor wrote: > tedd a écrit : >>> The issue remains the same. As programmers, we are all working with >>> the same internal formats for numbers, dates and hours. That's why >>> we can share snippets of code. Those internal formats are very >>> close, if not identical, to the formats used to display those items >>> in the USA. That's bad, not because those formats are not good, but >>> because it is easy for the US programmers to neglect their possible >>> international audience. For instance, in France, we use the coma for >>> the decimal point, the space char for the thousands separator, we >>> generally place the currency symbol at the end of the number, and >>> for hours we use the 24h format without even counting that all those >>> settings are customizable, therefore we must convert the values both >>> for input and output. >> Interesting. >> Regardless of international resources found in carbon and elsewhere, >> wouldn't it be best if a method was created that allowed the user to >> select the time and currency method that best suits his/her purpose >> in our applications? Something along a default snip-it that we could >> all add to our code to control/set time and date displays. >> Keep in mind that even those in the USA often want the date and time >> different, such as those in the military who want the date and time >> significantly different than civilians. >> Then again, perhaps I don't understand the problem, and I would guess >> considering the scope of the Global implications we are attempting to >> address, that none of us really do, but my solution would travel >> along such lines. > > For very specific needs why not, otherwise I have the feeling this > would be redundant with the International preference tool that already > allows us to customize those settings at the system level. Everyone > should rely upon the international resources just to take those > settings into account to begin with. While I haven't researched it thoroughly, I believe there are toolboxes that allow one to use any localized format available by specifying it, including the system default, which should take into account the current locale. Unfortunately, all of those options make them confusing to use, which is why our FB STR$ and VAL fns should automatically use the current locale, unless we all agree they should consistently use the US version. I can see benefits either way. ¢¢ e-e =J= a y "