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.htm...
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.htm...
Obviously for actual timestamps - e.g. created at/updated at times - we do store a point-in-time with fractional seconds.
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.
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.
Never trust user input though, of course :P