#2665 assigned enhancement

Convert _TOD_To_seconds to use mktime?

Reported by: Joel Sherrill Owned by: Needs Funding
Priority: normal Milestone: Indefinite
Component: score Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description

Our implementation of _TOD_To_seconds uses our own math. Given that this should be doing the equivalent of the POSIX method mktime(), I believe we should switch to that as the implementation of this method. At a minimum, this would ensure the implementation is correct. Worst case, it deletes some code which is hard to be sure it is 100% correct from our code base.

Change History (6)

comment:1 Changed on Mar 19, 2016 at 2:14:30 AM by Chris Johns

I changed rtems_clock_get_tod away from newlib a couple of years ago because of the 2038 bug and improved the implementation to not contain loops. I think performance is important in these calls.

Does the RTEMS call need to deal with timezones and the overhead it creates?

comment:2 Changed on Mar 19, 2016 at 3:02:52 PM by Joel Sherrill

No on timezones. This is strictly convert the time of day structure into a time_t. If you are happy with the implementation, then I am also. This was just a question from coming across this method while teaching the class and wondering.

I do think it needs to be a public method named something like rtems_clock_tod_to_seconds() or rtems_clock_tod_to_time_t(). It is used by the shared RTC driver by the private name.

comment:3 in reply to:  2 Changed on Mar 19, 2016 at 7:13:29 PM by Chris Johns

Replying to joel.sherrill:

No on timezones.

I think POSIX handles this so this would be a performance and size thing.

This is strictly convert the time of day structure into a time_t. If you are happy with the implementation, then I am also. This was just a question from coming across this method while teaching the class and wondering.

I would need to take a close look. I have not done this.

I do think it needs to be a public method named something like rtems_clock_tod_to_seconds() or rtems_clock_tod_to_time_t(). It is used by the shared RTC driver by the private name.

Good idea.

comment:4 Changed on Mar 21, 2016 at 7:33:10 AM by Sebastian Huber

We should first clearly define the time of day in RTEMS, see also #2189. There are reasons, why for example this code is a bit more complicated (e.g. leap seconds):

https://svnweb.freebsd.org/base/head/contrib/tzcode/stdtime/localtime.c?revision=289027&view=markup

comment:5 Changed on Mar 21, 2016 at 2:40:36 PM by Joel Sherrill

The original specifications RTEMS is based upon are here:

https://ftp.rtems.org/pub/rtems/people/joel/RTEID-ORKID/

to the best of my recollection, there is no mention of epoch, timezones, leap seconds, or leap years. The epoch of 1988 was chosen since it was the leap year immediately prior to the inception of RTEMS as a project.

At one point, the computation from tod to time_t did look like the reference in #2189.

I'm not trying to be argumentative but at this point, the score time is POSIX time and the tod returned is an alternative representation of that with the limitation that you can't set the time prior to 1988 via the Classic API.

Timezone is via the C Library and leap seconds would be the responsibility of ntp or other time syncing services.

This ticket is simply that this conversion doesn't look like a standard algorithm. The ticket you reference is asking to document the relationships of various time representations/APIs.

comment:6 Changed on Feb 15, 2017 at 2:20:42 PM by Sebastian Huber

Milestone: 4.12Indefinite
Owner: set to Needs Funding
Status: newassigned
Note: See TracTickets for help on using tickets.