I8ln argument types

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)

There was a previous request from @frinky for railo to to add LsParseDate which seems like an clear omission

I have copied it over to the lucee to the bug tracker https://luceeserver.atlassian.net/browse/LDEV-1552

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.

Regards

Ivan

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 :wink:
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…

Regards

Ivan

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?

@Zackster Zac, I wasn’t aware of that. This is great. I am sorry for polluting your thread with pointless comments.

nah, don’t worry about it, happy to to help!