You think timezones are annoying? Try handling metrics that use imperial and metric, need to be rounded to different precisions across a large system, and are sometimes recorded in a different unit than it’s viewed in. Slap some floating point error on there, and you got yourself a fun time.
I spent all day working on bug where backend was categorizing 19.9999 as falling between <20, but frontend was rounding it to 20 and categorizing it as >=20.
Edit: just to be clear, I don’t really think this is more difficult than date/time. But it does remind me a lot of solving date/time issues.
I would say your biggest issue here is needing precise decimal point computations and using imprecise data types. Any software that requires precision in the decimals needs to use types that are made for precise decimals. No floating point error.
For this specific project, I need max 2-3 decimal places of precision. So rounding really fixes all the issues. It’s more that we’re preventing the user from seeing awkward decimals. We aren’t doing rocket science. But understanding what metrics need what precision, and sometimes the same metric needs a different precision in different contexts.
You think timezones are annoying? Try handling metrics that use imperial and metric, need to be rounded to different precisions across a large system, and are sometimes recorded in a different unit than it’s viewed in. Slap some floating point error on there, and you got yourself a fun time.
I spent all day working on bug where backend was categorizing 19.9999 as falling between <20, but frontend was rounding it to 20 and categorizing it as >=20.
Edit: just to be clear, I don’t really think this is more difficult than date/time. But it does remind me a lot of solving date/time issues.
Hopefully you’re not working for NASA.
I remember talking about ths in early semesters of Software Engineer career in college
hey at least once your code is correct it’ll stay that way. You won’t have to deal with things like old and new versions of your program disagreeing on what time it was in Iran for the last month and a half of 1978
But have you ever try making a calendar?
https://zachholman.com/talk/utc-is-enough-for-everyone-right
Thanks, interesting read
I would say your biggest issue here is needing precise decimal point computations and using imprecise data types. Any software that requires precision in the decimals needs to use types that are made for precise decimals. No floating point error.
For this specific project, I need max 2-3 decimal places of precision. So rounding really fixes all the issues. It’s more that we’re preventing the user from seeing awkward decimals. We aren’t doing rocket science. But understanding what metrics need what precision, and sometimes the same metric needs a different precision in different contexts.