The company I work for is in international logistics (Flexport) so as you can imagine, dates and times are quite important. We have standardized internal time d

The company I work for is in international logistics (Flexport) so as you can imagine, dates and times are quite important. We have standardized internal time definitions that can represent uncertainty, which were the result of much discussion. I was surprised to learn there are ISO standards for time uncertainty, since I don't recall this ever coming up. This level of uncertainty would, I think, have too much flexibility for lots of normal business code. There is always an inherent tradeoff when writing code for use cases capturing real-world events between perfect fidelity of your model and coding ergonomics. Things about the real world are not known with perfect certainty, but if you can't capture them with discrete types (for example, CAR_STARTED vs. [Probability of CAR_STARTED = 99.9%, Probability of START_SENSOR_MALFUNCTION = 0.1%]), your downstream logic will be a huge mess. It can be cheaper to handle rare issues caused by lack of fidelity with business processes. Our time notion does not have as many degrees of freedom as this standard.