One

more small question. So to store money, integer fields, decimal fields, positive big integer field, how do

you like to do it? So we use decimal fields consistently. Okay,

and that works?

The arithmetics with decimal fields are what you want for money, unless you're on SQLite, but we don't use that in production. SQLite doesn't have a decimal field. It totally stores it, I believe, as a string, and then there's weird things with it when you try to do computation on it. But on PostgreSQL, I believe decimal field is a good fit, except that we will not be able to properly invoice in about seven of the currencies in the world because we have money stored decimal field with two decimal places, and there are, I think, seven currencies in the world that have three decimal places, mostly in the Arabic countries. And I'm not sure if we're ever going to be able to properly migrate those fields. 10 digits of two decimal tickets. We already needed to migrate to larger decimal field because I don't remember which currency it was. Some currency where you have these very large amounts where you buy conference tickets for a few million. But in the end, these differences are why I feel or why I'm quite happy with using decimal field, because if you're storing it in, so floating point is wrong. We can get that out of the way. Yes. Storing money and floating, as floating point numbers is wrong. Storing it as integers brings you to the same problem, because an American project is usually an integer of cents. But now you look at the Danish krona, which doesn't have a decimal part of the Japanese yen, or you look at the Jordanian dinar, which has three decimal places, and now either you would need to globally multiply by a thousand, even though that gives you integer representations of things that don't exist in US dollar, or you would need to have different multiplicators for different currencies, which sounds even worse. So the complexity there with the internationalization is the same, whether you're storing it in decimal fields or integers. There are a few advantages or disadvantages to either one.

Well, I'm about to launch something. So maybe I'll switch to decimal field because I have been using integer. So

the really, really bad thing is that a lot of the payment providers like PayPal or Stripe, by specifying their API, please submit the amount in integers of the smallest denomination of the currency. And there are some currencies, like I think the Danish Krona technically has a decimal point with two places behind it, but it hasn't been used in decades. And they don't publish whether they consider if the currency with decimal places or not so depending on the payment provided you might need to multiply it with 100 or not so um whatever you do document very clearly how you want other currencies to be handled yeah

well it seems like it's like time zones it sounds like oh money is money but just like time is not time zones are not

time zones it's quite complex we store the time of an event as a django date time but as times unaware but technically that's wrong we should be storing local time on a place because the time zone legislation changes before the because we're dealing with events in the future like um jango con 2025 is going to be in dublin ireland could abolish daylight saving time before it happens and then all the timestamps in our database would be wrong and we would need to like manually fix them for all the events that are taking place in ireland um so far that hasn't happened but yeah there's so much hidden complexity here good

the