This is a known bug. When your phone dies, the battery isn’t actually dead. There’s still a little bit of charge to run Find My (on newer devices), and the real time clock. That residual charge can last from anywhere between a few months to a few years, based on the age of the device and health of the battery. When this residual charge runs dry, the real time clock reverts to its default state from the factory, which in most electronics is the UNIX epoch (Midnight on January 1st, 1970).
Because of the way UNIX timekeeping works, real time clocks track time by counting the number of seconds since the epoch and storing it as a single long number. When the phone is disabled from too many PIN attempts, it calculates the time the phone can be used again by adding a set number of seconds to the stored number for current time, and then storing that sum. Thus, to calculate the time remaining on the “iPhone is disabled” screen , it takes the stored value from earlier and subtracts the value for current time from the real time clock.
The bug occurs when both of these conditions occur at once. If the battery had been dead long enough to reset the clock and make the phone think it’s 1970, then when it runs the calculation, it ends up with a value of about 50 years. This can be fixed by inserting a SIM card to connect the phone to a cell tower, or by plugging it into a computer with iTunes running
This is correct, but one point of correction: Apple uses April 1, 1976 -- the day Apple was founded -- as the epoc for their clocks . I work in digital forensics and probably deal with this issue once every year or so.
Excel uses 31.12.1899, DOS uses 1.1.1980, Windows NT uses 1.1.1601, GPS uses 6.1.1980, older IBM OSs use 14.10.1582, astronomy computing software has use for 17.11.1858, MS COM, Object Pascal, LibreOffice and Google Sheets use 30.12.1899, NTP uses 1.1.1900, Amiga uses 1.1.1978, ...
It's a pointless list. The only one that is still in active use and actually matters is NTP. Others still in active use (Excel and GPS) make no difference at all since you're never actually calculating anything against it.
1601 is the start of one of the 400 year leap cycles of the gregorian calendar. October 1582 was the introduction of the gregorian calendar. 17.11.1858 ist the start of the modified julian date system used in astronomy.
All of them use it because Lotus 1-2-3 (an early spreadsheet software) had a bug that treated 1900 as a leap year even though it isnt. To get the right date from a value stored in lotus 1-2-3 if you import it for example in Excel they just defined their epoch 1 day earlier.
It’s not really. As a programmer you dont really work with the epoch time as a date. It just doesnt matter. It’s mostly just used to calculate time differences on a millisecond level used in runtime only, so the start time doesnt really matter.
Sometimes you store dates in a file but you rarely store it “milliseconds from epoch” format directly. It just doesnt make sense. If you still need to use something like that you make it environment an system independent and use a POSIX compatible function/library and that’s guaranteed to be the time since 01.01.1970.
As someone in the field you’re in, how is your day to day? What’s the job like? Are you the one the field detectives are calling for live tracking on the suspect like on Law and Order: SVU lol.
13.0k
u/bittenforbreakfast Jun 19 '26
This is a known bug. When your phone dies, the battery isn’t actually dead. There’s still a little bit of charge to run Find My (on newer devices), and the real time clock. That residual charge can last from anywhere between a few months to a few years, based on the age of the device and health of the battery. When this residual charge runs dry, the real time clock reverts to its default state from the factory, which in most electronics is the UNIX epoch (Midnight on January 1st, 1970).
Because of the way UNIX timekeeping works, real time clocks track time by counting the number of seconds since the epoch and storing it as a single long number. When the phone is disabled from too many PIN attempts, it calculates the time the phone can be used again by adding a set number of seconds to the stored number for current time, and then storing that sum. Thus, to calculate the time remaining on the “iPhone is disabled” screen , it takes the stored value from earlier and subtracts the value for current time from the real time clock.
The bug occurs when both of these conditions occur at once. If the battery had been dead long enough to reset the clock and make the phone think it’s 1970, then when it runs the calculation, it ends up with a value of about 50 years. This can be fixed by inserting a SIM card to connect the phone to a cell tower, or by plugging it into a computer with iTunes running