5 ms·

> So if a policy starts at 00:00:00 and ends at 23:59:59, that's the full day, all the way up to midnight. If you had a policy for the calendar year 2016 would

> So if a policy starts at 00:00:00 and ends at 23:59:59, that's the full day, all the way up to midnight. If you had a policy for the calendar year 2016 would it not have covered 31 December 2016, 23:59:60 then? https://www.timeanddate.com/time/leap-seconds-background.html https://www.timeanddate.com/time/leap-seconds-background.htm...

solitus 8y ago
Claims are lodged by humans. I doubt any human would report they had a loss at 23:59:60 hehe!
- corobo 8y ago
  > I doubt any human Never trust user input though, of course :P
- daurnimator 8y ago
  What if the loss was caused by and at the leap second? e.g. imagine a self-driving car that ignored input during the leap second and crashed into a lane divider? You may have proof that the accident occurred at exactly 23:59:60.
  - sk5t 8y ago
    What if the car is flying through the air aside a suspension bridge at 23:59:59 and :60, and crashes into the water a second or two later? Has the loss occurred the moment the impact with terrain becomes inevitable, or not until impact?
ademarre 8y ago
Exactly. It's usually best to specify end times exclusively, and not just for leap seconds; it's easier to program in general. If your clock has sub-second granularity, then you can end up with a time value like 23:59:59.123. Which will require some truncation before it can be compared like t ≤ 23:59:59. If you use exclusive end times, you can do the comparison directly; 2016-12-31 23:59:59.123 < 2017-01-01 00:00:00. The key is that now we have an end date-time that actually specifies a true instant in time, and isn't an interval in and of itself.
- BillinghamJ 8y ago
  For that very reason, for start/end policy times, we store them aligned to the second - no fractional seconds allowed. There'd be no legal basis for that anyway. Obviously for actual timestamps - e.g. created at/updated at times - we do store a point-in-time with fractional seconds.
BillinghamJ 8y ago
Very fair point. From an operational perspective, if there was an incident in the second between 23:59:60 and midnight, it would of course be covered - irrespective of what's in any system, written on any doc, displayed in the app, etc. We don't worry too much about leap seconds - particularly as very few people are even likely to realise it was a factor, and the national Motor Insurance Database (MID) does not support them. The MID doesn't even allow us to specify timezones, so every year we sell around 20-30 one-hour car insurance policies which appear to run for 1 second - displaying the same start and end time on police computers etc. (Due to the clocks going back from BST to GMT.) From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes.
- filmor 8y ago
  > From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes. Well, apparently it's not if it's understood that it covers leap seconds as well. With regard to the internal modeling, I always go for half-open intervals, where the open side depends on the data being modeled, they have much nicer mathematical properties than closed intervals.

solitus 8y ago

Claims are lodged by humans. I doubt any human would report they had a loss at 23:59:60 hehe!

corobo 8y ago
> I doubt any human Never trust user input though, of course :P
daurnimator 8y ago
What if the loss was caused by and at the leap second? e.g. imagine a self-driving car that ignored input during the leap second and crashed into a lane divider? You may have proof that the accident occurred at exactly 23:59:60.
- sk5t 8y ago
  What if the car is flying through the air aside a suspension bridge at 23:59:59 and :60, and crashes into the water a second or two later? Has the loss occurred the moment the impact with terrain becomes inevitable, or not until impact?

ademarre 8y ago

Exactly. It's usually best to specify end times exclusively, and not just for leap seconds; it's easier to program in general. If your clock has sub-second granularity, then you can end up with a time value like 23:59:59.123. Which will require some truncation before it can be compared like t ≤ 23:59:59. If you use exclusive end times, you can do the comparison directly; 2016-12-31 23:59:59.123 < 2017-01-01 00:00:00. The key is that now we have an end date-time that actually specifies a true instant in time, and isn't an interval in and of itself.

BillinghamJ 8y ago
For that very reason, for start/end policy times, we store them aligned to the second - no fractional seconds allowed. There'd be no legal basis for that anyway. Obviously for actual timestamps - e.g. created at/updated at times - we do store a point-in-time with fractional seconds.

BillinghamJ 8y ago

Very fair point. From an operational perspective, if there was an incident in the second between 23:59:60 and midnight, it would of course be covered - irrespective of what's in any system, written on any doc, displayed in the app, etc. We don't worry too much about leap seconds - particularly as very few people are even likely to realise it was a factor, and the national Motor Insurance Database (MID) does not support them. The MID doesn't even allow us to specify timezones, so every year we sell around 20-30 one-hour car insurance policies which appear to run for 1 second - displaying the same start and end time on police computers etc. (Due to the clocks going back from BST to GMT.) From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes.

filmor 8y ago
> From a legal perspective, the time written on the policy doc is inclusive - we can't just decide that we want it to be exclusive because it suits our purposes. Well, apparently it's not if it's understood that it covers leap seconds as well. With regard to the internal modeling, I always go for half-open intervals, where the open side depends on the data being modeled, they have much nicer mathematical properties than closed intervals.