Should we document a time zone for the RTEMS epoch?

[Gedare Bloom]

On Wed, Feb 10, 2021 at 9:56 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Wed, Feb 10, 2021, 10:53 AM Sebastian Huber <
> sebastian.huber at embedded-brains.de> wrote:
>
>> On 10/02/2021 17:47, Joel Sherrill wrote:
>>
>> >
>> >
>> > On Wed, Feb 10, 2021, 10:30 AM Sebastian Huber
>> > <sebastian.huber at embedded-brains.de
>> > <mailto: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
>> >     <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?
>> The relevant epoch and clock is now referenced in the directives.
>> >
>> > And should there be discussion somewhere about TZ environment variable
>> > and the methods in newlib which account for that.
>> I think a time zone is simply not accounted for in the RTEMS Classic
>> API. With the setting above I guess the time zone is fixed to UTC.
>>
>
> By default clock_gettime is also UTC. You have to go through the C Library
> time methods to get timezones
>
>>
>>
This is an interesting topic. I would wager to guess that most users
implicitly assumed their own timezone/time basis (and likely didn't care,
as long it was consistent).

I think specifying it as zulu time is sensible.


> --
>> 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/b6c4b6cf/attachment.html>