Seems like a dump question, but why time needs to be signed? Guiding Li <ligd...@gmail.com> schrieb am Di., 5. Nov. 2024, 08:08:
> 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 >> >>
