I think that we should focus on fixing the 2038 issue and maintain compatibility with the existing code. We should not postpone the fix until later or break the compatibility for our users
Best regards Alin On Tue, Nov 5, 2024 at 8:08 AM Guiding Li <ligd...@gmail.com> wrote: > Hi Greg, > > Rather than reducing the size of time_t and joining the systems with the > year 2038 problem, I think that a better solution is to solve the problem > permanently. > --- > Agree with your last part, we should find a better way to ‘ put things > right once and for all ’, and not use the unsigned int to *postpone the > occurrence of things* > > So, Someone thinks time_t will overflow when set int32_t, should think > his code should open TIME64 or handle the overflow himself. > > > Gregory Nutt <spudan...@gmail.com> 于2024年11月5日周二 05:24写道： > >> You are right, there is no requirement by any standard that time_t be >> signed. Lots of discussion on Wikipedia: >> https://en.wikipedia.org/wiki/Unix_time >> >> The only motivation for making time_t signed is for compatibility with >> GLIBC. For example, some very old Unix systems permit negative time values >> for times before the epoch. The penalty for this compatibility with a >> non-standard different is a loss of range and the year 2038 problem. >> >> This is the year 2038 problem: >> https://en.wikipedia.org/wiki/Year_2038_problem >> >> Any product released after this change will fail in the field in 2038. >> That could be an issue for a few systems with very long lives. Most OSs >> have already fixed the year 2038 problem... but in different ways. See the >> Year_2038_Problem for solutions that are fielded now (one fix, ironically, >> is to make time_t unsigned). >> >> Rather than reducing the size of time_t and joining the systems with the >> year 2038 problem, I think that a better solution is to solve the problem >> permanently. >> >> >> On 11/4/2024 2:50 PM, b...@the-wanderers.org wrote: >> >> Hi Guiding, >> >> Both your reference and the Open Group specification documents both only >> state that POSIX requires time_t to be an integer type, not a signed >> integer. >> >> The Open Group Base Specifications Issue 8 >> <https://pubs.opengroup.org/onlinepubs/9799919799/> >> pubs.opengroup.org <https://pubs.opengroup.org/onlinepubs/9799919799/> >> [image: favicon.ico] <https://pubs.opengroup.org/onlinepubs/9799919799/> >> <https://pubs.opengroup.org/onlinepubs/9799919799/> >> >> GNU libc additionally mandates a signed integer but notes this is a GNU >> extension and not a POSIX requirement. >> >> The 2024 edition of POSIX has introduced a requirement for time_t to be >> 64 bits. As has already been noted this is itself a substantial change. >> >> Byron >> >> On 4 Nov 2024, at 11:33 PM, Guiding Li <ligd...@gmail.com> >> <ligd...@gmail.com> wrote: >> >> Hi all: >> >> We decide change 'time_t' from unsigned type to signed type in PR: >> https://github.com/apache/nuttx/pull/14460 >> >> Because when compile some POSIX library, there always be a warning on >> comparison >> between time_t and zero. >> >> For example: >> >> The following code will generate warnings: >> auto now = time(nullptr); >> auto last_active_time = GetEventService(self->ctx_)->getActiveTime(); if >> (last_active_time + 60 * 1000 / 1000 <= now) { >> >> src/ams/../controller/controller_timer.h: In lambda function: >> src/ams/../controller/controller_timer.h:117:57: warning: comparison of >> integer expressions of different signedness: 'long long int' and 'long >> long >> unsigned int' [-Wsign-compare] >> 117 | if (last_active_time + 60 * 1000 / 1000 <= now) { >> >> >> And we can find an reference on the official website: >> >> https://www.gnu.org/software/libc/manual/html_node/Time-Types.html >> >> On POSIX-conformant systems, time_t is an integer type. >> >> >> The comparation of the merits and shortcomings: >> >> Advantage: >> For the most POSIX applications they assume the time_t as signed and do >> compare with 0. >> The code will become more compatible after this modification. >> >> Disadvantage: >> None. >> >> >> If there is any question about this, please let me know. >> Thanks, >> Guiding >> >>
