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/>
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> 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
