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.
This is why, in any competent software dealing with physics in any way, it is always metric under the hood. Someone wants to see a quantity in some stupid freedom units? Fine sure convert it for them, but internally everything should be metric. Physics is hard enough, there's no reason to make it worse with an inconsistent unit system with built in footguns somehow.
I agree, storing in a consistent unit is the way. That doesn’t solve conversion/rounding issues, but it does simplify things.
Though you can run into floating point errors when editing in one unit vs storing in another. For example, maybe the user entered 2 in unit A, then it’s converted to unit B and stored in the db. However, when it’s converted back to unit A, it’s 1.999999. Fortunately rounding fixes this. We say unit A and B get 2 decimals of precision, and 1.999999 becomes 2.00.
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.
In money you can work in cents and round fractions to whole cents in someone's favour depending on policy for example my home accounting program rounds divided amounts up in transfers to the various accounts. It's pretty good right now with a can't being such an insignificant value.
Oh damn, I forgot to check which of my scheduled tasks were set to UTC, which were set to local time and whether they adjust automatically and what schedule the upstream tasks by different teams run on again.
Oh well, nobody cried about anything breaking yet, so I might be in the clear. For now.
One of the worst things about having DST at all is that it is not standardized through world. North America has not switched yet, and people making these announcements make me think my phone is broken.
The original post would be the result of subtracting the same date in two different time zones that are currently in different days. Whereas what you’re saying is basically just an under flow error.
20 Comments
moseschrute@lemmy.world · 67 pts · 311d
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.
FunctionallyLiterate@lemmy.ca · 28 pts · 311d
Hopefully you're not working for NASA.
capuccino@lemmy.world · 8 pts · 311d
I remember talking about ths in early semesters of Software Engineer career in college
azi@mander.xyz · 21 pts · 311d
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
sznowicki@lemmy.world · 12 pts · 311d
But have you ever try making a calendar?
https://zachholman.com/talk/utc-is-enough-for-everyone-right
_hovi_@lemmy.world · 5 pts · 311d
Thanks, interesting read
applebusch@lemmy.blahaj.zone · 8 pts · 310d
This is why, in any competent software dealing with physics in any way, it is always metric under the hood. Someone wants to see a quantity in some stupid freedom units? Fine sure convert it for them, but internally everything should be metric. Physics is hard enough, there's no reason to make it worse with an inconsistent unit system with built in footguns somehow.
moseschrute@lemmy.world · 2 pts · 310d
I agree, storing in a consistent unit is the way. That doesn’t solve conversion/rounding issues, but it does simplify things.
Though you can run into floating point errors when editing in one unit vs storing in another. For example, maybe the user entered 2 in unit A, then it’s converted to unit B and stored in the db. However, when it’s converted back to unit A, it’s 1.999999. Fortunately rounding fixes this. We say unit A and B get 2 decimals of precision, and 1.999999 becomes 2.00.
iglou@programming.dev · 3 pts · 310d
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.
moseschrute@lemmy.world · 1 pts · 310d
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.
psud@aussie.zone · 1 pts · 300d
In money you can work in cents and round fractions to whole cents in someone's favour depending on policy for example my home accounting program rounds divided amounts up in transfers to the various accounts. It's pretty good right now with a can't being such an insignificant value.
Whelks_chance@lemmy.world · 16 pts · 311d
Tom Scott's video is about to do the rounds again then
panda_abyss@lemmy.ca · 7 pts · 311d
Reading the pytz time zone database is an insane and engaging read.
Nobody is ever going to solve that problem.
luciferofastora@feddit.org · 6 pts · 310d
Oh damn, I forgot to check which of my scheduled tasks were set to UTC, which were set to local time and whether they adjust automatically and what schedule the upstream tasks by different teams run on again.
Oh well, nobody cried about anything breaking yet, so I might be in the clear. For now.
Cevilia@lemmy.blahaj.zone · 5 pts · 310d
python@lemmy.world · 3 pts · 310d
The switch to winter time was last sunday, it's been a fun week at work so far.
humanspiral@lemmy.ca · 5 pts · 310d
One of the worst things about having DST at all is that it is not standardized through world. North America has not switched yet, and people making these announcements make me think my phone is broken.
AmazingAwesomator@lemmy.world · 1 pts · 311d
underflow
locuester@lemmy.zip · 1 pts · 310d
Would be better as 4,294,967,295 instead of -1.
fahfahfahfah@lemmy.billiam.net · 2 pts · 310d
The original post would be the result of subtracting the same date in two different time zones that are currently in different days. Whereas what you’re saying is basically just an under flow error.
locuester@lemmy.zip · 3 pts · 310d
What I’m saying is just a level deeper for comp sci people. It’s the same thing, but expressed on a 32-bit unsigned integer.
Same result. Deeper joke.