<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>Animats</author><text>Underflow occurs because applying the time zone offset to a time of zero can generate a negative time. UNIX time is UTC internally.</text><parent_chain><item><author>fpgaminer</author><text>I learned about this yesterday from a Tom Scott video (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=MVI87HzfskQ&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=MVI87HzfskQ&lt;/a&gt;).  I find it odd that his sources are suggesting that this is an integer underflow bug.  First, while integer underflow itself would be a bug in this case (if it&amp;#x27;s occurring) the real bug would be not handling large time values.  If they are indeed using u64 to store time, the system should be designed to, you know, handle u64.  Why would parts of the system break for values like 0xFFFFFFFFFFFFFFFF?&lt;p&gt;Second, and this is more important, iOS likely is _not_ using u64.  It&amp;#x27;s a BSD derivative, so it&amp;#x27;s using time_t, which is signed.  No underflow involved.  It just literally goes negative.  And this is far more likely to be the cause of the issue.  In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) &amp;lt; 0) { halt_and_catch_fire(); }` or `while (time(NULL) &amp;lt; 0); &amp;#x2F;&amp;#x2F; wait for RTC to start up`.  That&amp;#x27;s more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.&lt;p&gt;The take away?  My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don&amp;#x27;t return negative values as error codes.  Wrap broken functions like `time` into functions that return the time and an error code separately.  If you&amp;#x27;ll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it&amp;#x27;s worth representing.</text></item></parent_chain></comment><story><title>Changing Date to Jan 1, 1970 disables 64-bit iOS devices</title><url>https://www.reddit.com/r/jailbreak/comments/458ao3/discussion_changing_time_date_settings_to_jan_1/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>thought_alarm</author><text>All we know is that boot-up fails on 64-bit hardware.  We don&amp;#x27;t have nearly enough information to accurately guess which boot-time component is failing or what API this component is using.&lt;p&gt;A trivial example would be casting an `unsigned int` to a `time_t` (i.e., `long`).  It will work with negative numbers on 32-bit systems, but will fail with negative numbers on 64-bit systems.</text><parent_chain><item><author>fpgaminer</author><text>I learned about this yesterday from a Tom Scott video (&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=MVI87HzfskQ&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;www.youtube.com&amp;#x2F;watch?v=MVI87HzfskQ&lt;/a&gt;).  I find it odd that his sources are suggesting that this is an integer underflow bug.  First, while integer underflow itself would be a bug in this case (if it&amp;#x27;s occurring) the real bug would be not handling large time values.  If they are indeed using u64 to store time, the system should be designed to, you know, handle u64.  Why would parts of the system break for values like 0xFFFFFFFFFFFFFFFF?&lt;p&gt;Second, and this is more important, iOS likely is _not_ using u64.  It&amp;#x27;s a BSD derivative, so it&amp;#x27;s using time_t, which is signed.  No underflow involved.  It just literally goes negative.  And this is far more likely to be the cause of the issue.  In POSIX systems, many time fetching functions return -1 as an error code, and I can easily see some programmer doing `if ((t = time(NULL)) &amp;lt; 0) { halt_and_catch_fire(); }` or `while (time(NULL) &amp;lt; 0); &amp;#x2F;&amp;#x2F; wait for RTC to start up`.  That&amp;#x27;s more likely, in my opinion, than some part of iOS using u64 for time and not handling large values.&lt;p&gt;The take away?  My fellow engineers, please stick with time specific types (like time_t) that are i64 underneath, and please don&amp;#x27;t return negative values as error codes.  Wrap broken functions like `time` into functions that return the time and an error code separately.  If you&amp;#x27;ll recall from those history classes in high school and college, time before 1970 was fairly important (though clearly not as exciting without iPhones), so it&amp;#x27;s worth representing.</text></item></parent_chain></comment><story><title>Changing Date to Jan 1, 1970 disables 64-bit iOS devices</title><url>https://www.reddit.com/r/jailbreak/comments/458ao3/discussion_changing_time_date_settings_to_jan_1/</url></story>