at the moment, argument validation doesn’t support localised values for dates or numbers
what do people think about adding about adding LsNumeric and LsDate as argument types?
(also, a bit weird that lsParseDate won’t parse 1-12-2017 as a valid date for the Australian Locale?
Lucee does better than ACF with English US, but it’s still inconsistent for other locales)
Well, for example in my country we use comma as a decimal separator.
I have always considered this to be an unlucky deviation from a common standard.
But for other people is the other way round. So people keep inputing numbers like 1,5 everywhere.
It is easy thing to fix in one’s own code, but not so easy when it comes to 3rd party code which often breaks. ( isNumeric('1,5') = false )
Sure, it would be nice to have LsIsnumeric and LsParseNumber function.
But there wouldn’t be much improvement until everyone implements it.
I see where you are coming from and i understand the frustration.
Type conversion specially when it comes to dates is a mess in CFML. that is because the language need to support a lot different formats sadly this formats are not soley based on the locale defined in the system, what would be nice.
having a type ls is a nice approach, but ls is not really a type it is a way to tell lucee how to convert a certain type to an other. the result will still be a date and not an lsDate.
That is the reason i’m not really for it, it adds more cinfusion to that topic. it does not reduce it.
So how we could approach this. Actually we already did this for “Lucee Lang” , “Lucee Lang” handles dates, number … purely with locale based converters.
Bad sadly that does not really help us with CFML.
So again how could we solve it
Allow to define in the admin or application.cfc how lucee convert types. as example this couild look in the application.cfc as follows:
component {
this.typeparsing.date="locale"; // can be "locale" or "classic"
this.typeparsing.number="locale"; // can be "locale" or "classic"
this.
}
(there are for sure better names than “typeparsing”)
Yes. I totally understand you are not really for it. I also think normal decimal separarator is dot and that’s it.
I just wanted to add some real world use case to this discussion.
It is not really source of some frustration. I simply have to live with it the same way I have to live with various accented characters which are normally part of our alphabet etc. People in different countries have to deal with different set of similar issues.
For sure, parsing various funny number and date formats would be a mess from the Lucee language point of view.
It is very open ended - number formats with a thousand separator like 1.000,5 are also quite common…
Believe me i know where you are coming from. i live in a country that i can pass in 2 hours by car but we have 4 different locales.
Locale based type conversions makes a lot of sense for me, that is the reason we added support for “locale” and “timezone” to all functions it makes sense.
@Ivan_Rotrekl what do you mean by “Sure, it would be nice to have LsIsnumeric and LsParseNumber function.”
I also just noticed the docs were missing a Internationalization category so…
@micstriit wouldn’t a global the type parsing option possibly break a lot of stuff? that’s why I suggested a new argument type so it’s explicitly opt in?