<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021, 10:53 AM Sebastian Huber <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 10/02/2021 17:47, Joel Sherrill wrote:<br>
<br>
><br>
><br>
> On Wed, Feb 10, 2021, 10:30 AM Sebastian Huber <br>
> <<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a> <br>
> <mailto:<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a>>> wrote:<br>
><br>
> On 10/02/2021 07:53, Sebastian Huber wrote:<br>
><br>
> > Hello,<br>
> ><br>
> > I try to update the clock manager documentation and noticed that<br>
> there<br>
> > is no time zone specified for the RTEMS epoch. In the timecounter<br>
> > initialization we use:<br>
> ><br>
> > static struct timehands th0 = {<br>
> > [...]<br>
> > #ifdef __rtems__<br>
> > .th_bintime = { .sec = TOD_SECONDS_1970_THROUGH_1988 },<br>
> > .th_microtime = { TOD_SECONDS_1970_THROUGH_1988, 0 },<br>
> > .th_nanotime = { TOD_SECONDS_1970_THROUGH_1988, 0 },<br>
> > .th_boottime = { .sec = TOD_SECONDS_1970_THROUGH_1988 - 1 },<br>
> > #endif /* __rtems__ */<br>
> ><br>
> > [...]<br>
> ><br>
> > };<br>
> ><br>
> > Since Unix epoch is 1970-01-01T00:00:00Z, this basically defines<br>
> that<br>
> > the RTEMS epoch is 1988-01-01T00:00:00Z. Should this be documented?<br>
> > The current implementation also implies that the time reported by<br>
> > RTEMS is in UTC (modulo leap seconds).<br>
><br>
> I tried to document the clocks provided by RTEMS, see tail of<br>
> (glossary.rst):<br>
><br>
> <a href="https://lists.rtems.org/pipermail/devel/2021-February/064451.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2021-February/064451.html</a><br>
> <<a href="https://lists.rtems.org/pipermail/devel/2021-February/064451.html" rel="noreferrer noreferrer" target="_blank">https://lists.rtems.org/pipermail/devel/2021-February/064451.html</a>><br>
><br>
><br>
> Is it sufficient to reference the epoch entry in various clock get <br>
> time method pages?<br>
The relevant epoch and clock is now referenced in the directives.<br>
><br>
> And should there be discussion somewhere about TZ environment variable <br>
> and the methods in newlib which account for that.<br>
I think a time zone is simply not accounted for in the RTEMS Classic <br>
API. With the setting above I guess the time zone is fixed to UTC.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">By default clock_gettime is also UTC. You have to go through the C Library time methods to get timezones</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
-- <br>
embedded brains GmbH<br>
Herr Sebastian HUBER<br>
Dornierstr. 4<br>
82178 Puchheim<br>
Germany<br>
email: <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank" rel="noreferrer">sebastian.huber@embedded-brains.de</a><br>
phone: +49-89-18 94 741 - 16<br>
fax: +49-89-18 94 741 - 08<br>
<br>
Registergericht: Amtsgericht München<br>
Registernummer: HRB 157899<br>
Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler<br>
Unsere Datenschutzerklärung finden Sie hier:<br>
<a href="https://embedded-brains.de/datenschutzerklaerung/" rel="noreferrer noreferrer" target="_blank">https://embedded-brains.de/datenschutzerklaerung/</a><br>
<br>
</blockquote></div></div></div>