<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 5, 2018 at 3:51 AM, jaeho jo <span dir="ltr"><<a href="mailto:hot486two@gmail.com" target="_blank">hot486two@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">UNIX time starts in 1970, but RTEMS starts from 1988.<div><br></div><div>Unix time cannot encode times after 03:14:07 UTC on 19 January 2038.</div><div><br></div><div>What is the maximum value of rtems time of day? 2038 + 18 => 2056? <br></div></div></blockquote><div><br></div><div>There is no enforced maximum. The practical limit where the year value</div><div>causes issues technically depends on the RTEMS version. </div><div><br></div><div>For very old versions, that was the internal time format so 2038 didn't matter </div><div>for those calls. It did matter if you tried to get/set using POSIX calls.</div><div><br></div><div>Around 4.8, the internal went to 32-bit time_t POSIX and 2038 was the limit.</div><div><br></div><div>I think 4.11 mostly used an internal 64-bit time but it was still 32 bit time_t</div><div>for POSIX APIs.</div><div><br></div><div>For the master (aka 5), it is 64 bit POSIX time_t so everything should be</div><div>clean for long term time.</div><div><br></div><div>--joel</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div><br></div><div>thanks.</div></div>
<br>______________________________<wbr>_________________<br>
users mailing list<br>
<a href="mailto:users@rtems.org">users@rtems.org</a><br>
<a href="http://lists.rtems.org/mailman/listinfo/users" rel="noreferrer" target="_blank">http://lists.rtems.org/<wbr>mailman/listinfo/users</a><br></blockquote></div><br></div></div>