Should we document a time zone for the RTEMS epoch?

[Joel Sherrill]

On Wed, Feb 10, 2021, 10:30 AM Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> On 10/02/2021 07:53, Sebastian Huber wrote:
>
> > Hello,
> >
> > I try to update the clock manager documentation and noticed that there
> > is no time zone specified for the RTEMS epoch. In the timecounter
> > initialization we use:
> >
> > static struct timehands th0 = {
> > [...]
> > #ifdef __rtems__
> >     .th_bintime = { .sec = TOD_SECONDS_1970_THROUGH_1988 },
> >     .th_microtime = { TOD_SECONDS_1970_THROUGH_1988, 0 },
> >     .th_nanotime = { TOD_SECONDS_1970_THROUGH_1988, 0 },
> >     .th_boottime = { .sec = TOD_SECONDS_1970_THROUGH_1988 - 1 },
> > #endif /* __rtems__ */
> >
> > [...]
> >
> > };
> >
> > Since Unix epoch is 1970-01-01T00:00:00Z, this basically defines that
> > the RTEMS epoch is 1988-01-01T00:00:00Z. Should this be documented?
> > The current implementation also implies that the time reported by
> > RTEMS is in UTC (modulo leap seconds).
>
> I tried to document the clocks provided by RTEMS, see tail of
> (glossary.rst):
>
> https://lists.rtems.org/pipermail/devel/2021-February/064451.html


Is it sufficient to reference the epoch entry in various clock get time
method pages?

And should there be discussion somewhere about TZ environment variable and
the methods in newlib which account for that.



>
> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber at embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210210/aa20efa1/attachment.html>