Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow
It is reasonable. Let's capture the analysis. I thought there was a place we had notes related to different time source overflows, but I can't find it quickly On Mon, Apr 19, 2021 at 9:44 AM Sebastian Huber wrote: > > On 13/04/2021 18:03, Sebastian Huber wrote: > > > Hello, > > > > On 08/04/2021 15:41, Frank Kuehndel wrote: > >> +/** > >> + * @brief Latest year to which a time of day can be initialized. > >> + * > >> + * The following constant defines the latest year to which an > >> + * RTEMS time of day can be set using rtems_clock_set(). > >> + * > >> + * 32 bits can accept as latest point in time 2106-Feb-7 6:28:15 > >> + * but to simplify the implementation, is was decided to only > >> + * check that the year is not greater than the year of this constant. > >> + * > >> + * The internal realtime clock can run centuries longer but in > >> + * contrast to the POSIX API, the RTEMS Classic API does not > >> + * support this for efficiency reasons. > >> + */ > >> +#define TOD_LATEST_YEAR 2105 > > > > any objections to use this approach? If we want to support years after > > 2105 in the Classic API, then we would need 64-bit values and > > calculations in several places. I think an RTEMS system which operates > > after 2105 is currently a bit unrealistic. > > > > If we limit the time frame to the year 2100 we could simplify > > _TOD_Validate() a bit more since all years % 4 == 0 are leap years in > > the range 1988 to 2100 (exclusive). > If there are no objections, then I will check this in on Wednesday and > send a documentation update. > > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@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@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow
On 13/04/2021 18:03, Sebastian Huber wrote: Hello, On 08/04/2021 15:41, Frank Kuehndel wrote: +/** + * @brief Latest year to which a time of day can be initialized. + * + * The following constant defines the latest year to which an + * RTEMS time of day can be set using rtems_clock_set(). + * + * 32 bits can accept as latest point in time 2106-Feb-7 6:28:15 + * but to simplify the implementation, is was decided to only + * check that the year is not greater than the year of this constant. + * + * The internal realtime clock can run centuries longer but in + * contrast to the POSIX API, the RTEMS Classic API does not + * support this for efficiency reasons. + */ +#define TOD_LATEST_YEAR 2105 any objections to use this approach? If we want to support years after 2105 in the Classic API, then we would need 64-bit values and calculations in several places. I think an RTEMS system which operates after 2105 is currently a bit unrealistic. If we limit the time frame to the year 2100 we could simplify _TOD_Validate() a bit more since all years % 4 == 0 are leap years in the range 1988 to 2100 (exclusive). If there are no objections, then I will check this in on Wednesday and send a documentation update. -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] clock:_TOD_To_seconds(): Fix year 2514 overflow
Hello, On 08/04/2021 15:41, Frank Kuehndel wrote: +/** + * @brief Latest year to which a time of day can be initialized. + * + * The following constant defines the latest year to which an + * RTEMS time of day can be set using rtems_clock_set(). + * + * 32 bits can accept as latest point in time 2106-Feb-7 6:28:15 + * but to simplify the implementation, is was decided to only + * check that the year is not greater than the year of this constant. + * + * The internal realtime clock can run centuries longer but in + * contrast to the POSIX API, the RTEMS Classic API does not + * support this for efficiency reasons. + */ +#define TOD_LATEST_YEAR 2105 any objections to use this approach? If we want to support years after 2105 in the Classic API, then we would need 64-bit values and calculations in several places. I think an RTEMS system which operates after 2105 is currently a bit unrealistic. If we limit the time frame to the year 2100 we could simplify _TOD_Validate() a bit more since all years % 4 == 0 are leap years in the range 1988 to 2100 (exclusive). -- embedded brains GmbH Herr Sebastian HUBER Dornierstr. 4 82178 Puchheim Germany email: sebastian.hu...@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@rtems.org http://lists.rtems.org/mailman/listinfo/devel
