On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > It is reasonable to force an upper bound for the various methods of setting > CLOCK_REALTIME. Year 2262 is the absolute upper bound. Assume a maximum > uptime of 30 years which is plenty enough even for esoteric embedded > systems. That results in an upper bound of year 2232 for setting the time.
The patch looks good to me. I like this approach better than using a larger value closer to the overflow (e.g. one week) and stepping the clock back automatically when the clock reaches that time, but I suspect it might possibly break more tests (or any unusual applications messing with time) as a much larger interval is now EINVAL. Thanks, -- Miroslav Lichvar
