Having a rationale is good, contradicting real use-cases is not so much. I met validations that are constructed without a lot of cases in mind lots of times. My favourite one was assuming the zip code is always 5–6 numbers, which is not always the case in length and in some countries it's not numbers at all, and that was a logistical company that was supposed to know things well

also mobile numbers are a bad identity vector. Some keep theirs for decades, others may change them several times a year every year.

True. I guess given that the way I've always done it here (one contacts the bank directly to open a new joint account) rather than trying to add a second person to an existing account, I hadn't considered that approach. Still, I can somewhat understand the rationale behind this design.

It's perfectly reasonable for a couple to have their own accounts plus a joint account.

Unfortunately this somewhat makes sense... Now, if her account has been closed, then this is a design flaw. But if it's still there - just hasn't been used in ages - then this sanity-check makes sense to prevent fraud.

Maybe.
I don't know how it gives so much of a drift though.

Maybe a daylight savings time issue?

Considering it is multiple days, I'd guess it's not just timezone issue.

Seemingly not a piefed issue specifically

No noticing any issues here. Could it be somehow related to piefed? I even looked at some of the communities in your screenshot and everything looked normal

123456789. Possible

CSS was a mistake

0.1f64 + 0.2f64 != 0.3f64

It does if you round it to the nearest penny.

Encoding in assumptions about a fixed amount of supported currencies in a system is broadly speaking not a good idea

Most sensible programming languages allow enums to be non-exhaustive.

Yes you can. You're vastly underestimating the size of an f64. Give me a concrete example of a money operation that fails with f64 (for normal companies; assuming you aren't a stock exchange or Visa or whatever).

0.1f64 + 0.2f64 != 0.3f64

Why not?

Encoding in assumptions about a fixed amount of supported currencies in a system is broadly speaking not a good idea

Remember to take your payout in the form of cash.

Double is not perfectly precise. It is quite literally a function that calculates what the value should be. There are converters to show the drift: https://www.h-schmidt.net/FloatConverter/IEEE754.html

$40.01 is literally stored as 01000010001000000000101000111101 in a float type, which is literally stored as 40.009998321533203125. The margin of error goes up the larger the number.

No you're fundamentally misunderstanding what's going on. Float isn't "storing 40.01 but imprecisely". That's like saying an integer "stores 1.1 but imprecisely". Floating point can't represent the number 40.01. But that doesn't matter because 4.0009999999999998 is easily accurate enough for any real world use.

The story of Ariane 5

This was caused by converting an f64 to i16 which caused an overflow and hardware exception. Irrelevant.

How a Minor Calculation Error Cost Intel Half a Billion Dollars

Hardware bug. Irrelevant.

Wikipedia

Literally says "The failure to intercept arose not from using floating point specifically"

and asking the stock exchange

I'm not talking about stock exchanges. Obviously they have extreme requirements. For most normal businesses and people f64 is fine.

You're repeating dogma without thinking about it.

Yes you can. You're vastly underestimating the size of an f64. Give me a concrete example of a money operation that fails with f64 (for normal companies; assuming you aren't a stock exchange or Visa or whatever).

You can't use it if you ever want to do any operations on said money, due to the loss of prescision.

Enums are not a good idea for the currencies either.

or office space!

It feels weird at first, but it really is the best safest way to store the auditable amount, and really most of the time with currency you don't need to ever mutate it at the DB level, so why introduce the possibility at all of a precision error. One thing that is common is that you do a order by of your transactions, which is why the imprecise is useful, but then you display the string version to the user. It also keeps the precision rather than truncating the precision off (with money the .00 is important, most banks require exact precision to know that you didn't accidentally have a rounding/truncation error)

re your last point: or just watch Superman III.

Have you seen office space?

best practice is to store the "imprecise" amount next to it as whatever the database supports. That way, you have the auditable real value ($4.00) stored for use on reports and taxes, and the imprecise ($3.99999999898998888181)

Lol, that feels exactly like writing 'four (4)' in a sentence, I love it