[RTEMS Project] #4338: rtems_clock_set(): Cannot set future dates later than approximately 2105

RTEMS trac trac at rtems.org
Wed Apr 21 05:19:03 UTC 2021


#4338: rtems_clock_set(): Cannot set future dates later than approximately 2105
-------------------------------------------------+-------------------------
 Reporter:  Frank Kuehndel                       |       Owner:  Sebastian
                                                 |  Huber
     Type:  defect                               |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.1
Component:  rtems                                |     Version:  6
 Severity:  normal                               |  Resolution:
 Keywords:  rtems_clock_set, 2514,               |  Blocked By:
  _TOD_To_seconds                                |
 Blocking:                                       |
-------------------------------------------------+-------------------------

Comment (by Frank Kühndel <frank.kuehndel@…>):

 In [changeset:"7bbbe4225c92b646faa14e5f5800ed2feba09899/rtems"
 7bbbe42/rtems]:
 {{{
 #!CommitTicketReference repository="rtems"
 revision="7bbbe4225c92b646faa14e5f5800ed2feba09899"
 clock:_TOD_To_seconds(): Fix year 2514 overflow

 This patch fixes issue #4338 by changing _TOD_Validate()
 to only accept years till 2105. This requires another patch
 to change the documentation of rtems_clock_set() and other
 affected API functions (indicating the end date is 2105 not 2514).

 I tried to support till year 2514 but it turned out that
 this needs changing the Timer Manager too. That in turn
 would mean to change _TOD_Seconds_since_epoch( void )
 from 32 to 64 bit. Sebastian pointed out that a naive extension
 leads to trouble with 32 bit processors. He deemed a safe
 re-implementation too costly performance wise considering
 that year 2106 is far away and current binaries using RTEMS
 Classic API are unlikely to be in use by 2106.

 The constant TOD_SECONDS_AT_2100_03_01_00_00 in
 cpukit/rtems/src/clocktodtoseconds.c happens to be wrong by
 1 hour. When setting the date 2100-Feb-28 23:59:59 and then
 reading the date again you will find yourself in 2100-Feb-27.

 Update #4338
 }}}

--
Ticket URL: <http://devel.rtems.org/ticket/4338#comment:5>
RTEMS Project <http://www.rtems.org/>
RTEMS Project


More information about the bugs mailing list