The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
There were 2 concepts. COUNTING, which everyone had to learn how to do.
And NOBODY bothered COUNTING ZERO of something. Does a cow farmer record ZERO Sheep, ZERO Goats, etc... Nope, he counts cows... And if the count is ZERO... I am certain he is in PANIC mode. LOL
The other concept was MATH. And that is where ZERO is a strict requirement.
And we learn numbers first, then math to this day, but we learn more math sooner.
Also, I have a daughter, I remember teaching her to count. I can't remember teaching her to start at ZERO.
Here is something interesting about the NAMES for our numbers. Which are NOT good names in English. Because we USED to use BASE 12. The repetition parallel naming starts at 21 (21, 31, 41).
But not 11 (which should be tenny-one, or ten-1 or One-teen [best]... Indicating 10 Plus one)
But because we used to be base 12 (12 inches in a foot, 12 in dozen, etc)... the TEENS start at 13.
Also, implied... Many people were counting much passed this.
And mathematically speaking... Base 12 was superior. It divides by 2,3 and 4. Something 10 cannot do without decimals.
And don't get me started with decimals. try that in ROMAN Numerals. In fact, division of Roman Numerals (without converting to decimal in your head), takes YEARS to master.
So, now we realize we have COUNTING, MATH, and REPRESENTATION...
The last one becomes important. How many times have you seen someone open and close their hands to tell you a bigger number like 20, or 30... Do that using Hexadecimal Representation. LOL...
Got an ASP.NET MVC Core app with a SQL Server database.
I have a decimal field in the database, gets correctly converted to decimal in .NET, and then it gets send to the front-end as-is (1.2).
The input (type="number") shows 1,2 (one comma two), but when I send it to the back-end it's converted to 12.
Even 1.2 (one dot two) is saved as 12.
Even when I do absolutely nothing my number is converted to 12.
I'm sure there's a good explanation, like Vue.js messing up my numeric fields or whatever.
Googling the problem gives me all kinds of libraries for working with numbers.
I'm so happy that after about 30 years of web development we can finally handle numbers without hassle
Guess I'll just be happy I'm not working with dates.
Or worse, CSS.
The browser posts a double as "1.2" in JSON (independent of culture I hope) and .NET Core does the deserialization (hopefully also independent of culture).
Even after changing my separator in Windows from comma to dot the deserialization only works with comma.
I'm just baffled that "1.2" is deserialized as 12 and only "1,2" is deserialized as 1.2
Apparently, I wasn't posting JSON at all...
The entire thing got posted as form data and that uses different deserialization rules for obvious(???) reasons
Changed the type of AJAX to JSON and 1.22 is now serialized as 1.22 (but 1,22 is completely invalid ).
Culture's probably not the problem (if it is it's between browser and back-end, not DB and back-end).
It's posted as string "1.2" (no matter if the separator in the input is actually a comma or dot) and .NET converts that to a whole number.
It's probably a string because it's bound (with Vue.js) to an input and inputs are always strings.
Anyway, you'd think that converting "1.2" to 1.2 before posting would solve the problem.
Unfortunately, it doesn't...
And here I was thinking saving some data was going to be easy
I primarily work WPF and that does a great job of converting. However, I recently worked on a project where I had problems with converting number, and so had to do some work arounds. Funny thing was I could not reproduce the problem in a sample project. Go figure.