I think the clock that Apple OSes use is based on Apple Epoch time, which is 1/1/2000 UTC, and is represented by a double floating point value in seconds so it handles underflow and overflow quite well, many hundreds of centuries both ways. I believe that the underlying BSD implementation sits on top of this – if you ask for UNIX Epoch time it takes the current Apple time and subtracts 30 years, and converts it to a 64-bit integer.
(There might be an even lower level, kernel based clock which would be a signed 64 bit integer, but would not be susceptible to underflow or overflow)
I have 2 hypotheses of why it crashes: 1. there’s some security feature (cellular authentication?) that requires the clock be set to within a reasonable range of external clocks (cell towers) for “normal” (non-crash) operation. 2. the phone’s calendar daemon attempts to calculate it’s to-do list and chokes on some integer overflow because it wasn’t really designed to calculate the past 40 year’s worth of recurring events.
Signed,
someone who knows just enough about Apple OS internals to make wildly inaccurate statements.
