Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001462 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Enhancement Request 2021-03-26 15:34 2021-03-26 15:34
Reporter geoffclare View Status public  
Assigned To
Priority normal Resolution Open  
Status New  
Name Geoff Clare
Organization The Open Group
User Reference
Section time()
Page Number 2149
Line Number 68870
Interp Status ---
Final Accepted Text
Summary 0001462: Require (at least) 64-bit time_t
Description The time() FUTURE DIRECTIONS section says:
In a future version of this volume of POSIX.1-2017, time_t is likely to be required to be capable of representing times far in the future. Whether this will be mandated as a 64-bit type or a requirement that a specific date in the future be representable (for example, 10000 AD) is not yet determined.
The time to do something about this is now, as the next major revision is likely to be at least ten years after this one, which will be uncomfortably close to 2038.

Note that if time_t is required to be 64-bit, implementations can still support legacy programming environments where time_t is 32-bit. In order to conform, there just needs to be at least one environment where time_t is 64-bit. (The suggested changes include additions advising about this.)
Desired Action On page 2050 line 65758 section strftime() RATIONALE, change:
With tm_year being a signed 32 or more-bit int and with many current implementations supporting 64-bit time_t types in one or more programming environments, these assumptions are clearly wrong.
to:
Since tm_year is a signed int with a width of at least 32 bits and time_t is required to have a width of at least 64 bits (in conforming programming environments), these assumptions no longer hold.

On page 2149 line 68857 section time() RATIONALE, change:
Implementations in which time_t is a 32-bit signed integer (many historical implementations) fail in the year 2038. POSIX.1-2017 does not address this problem. However, the use of the time_t type is mandated in order to ease the eventual fix.
to:
Earlier versions of this standard allowed the width of time_t to be less than 64 bits. A 32-bit signed integer (as used in many historical implementations) fails in the year 2038, and although a 32-bit unsigned integer does not fail until 2106 the preferred solution is to make time_t wider rather than to make it unsigned.

On page 2149 line 68870 section time(), change FUTURE DIRECTIONS to:
None.

Cross-volume changes to XBD ...

On page 404 line 13726 section <sys/types.h>, change:
  • clock_t shall be an integer or real-floating type. [CX]time_t shall be an integer type.[/CX]
to:
  • clock_t shall be an integer or real-floating type.

  • [CX]time_t shall be an integer type with a width (see [xref to <stdint.h>]) of at least 64 bits.[/CX]

On page 450 line 15504 section <unistd.h> APPLICATION USAGE, add a new paragraph:
Implementations may support multiple programming environments with some of them conforming to this standard and some not conforming. The _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants, and corresponding sysconf() and getconf calls, only indicate whether each programming environment is supported; they do not indicate anything about conformance of the environments that are supported. For example, an implementation may support the ILP32_OFF32 environment for legacy reasons with a 32-bit time_t, whereas in a conforming environment time_tis required to have a width of at least 64 bits. Application writers should consult an implementation's POSIX Conformance Document for information about the conformance of each supported programming environment.

Cross-volume changes to XCU ...

On page 2546 line 82421 section c99 EXTENDED DESCRIPTION, change:
Applications can use sysconf() or getconf to determine which programming environments are supported.
to:
Applications can use the _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, to determine which programming environments are supported.

On page 2549 line 82527 section c99 APPLICATION USAGE, add a new paragraph:
Implementations may support multiple programming environments with some of them conforming to this standard and some not conforming. The _POSIX_Vn_ILP* and _POSIX_Vn_LP* constants in <unistd.h>, and corresponding sysconf() and getconf calls, only indicate whether each programming environment is supported; they do not indicate anything about conformance of the environments that are supported. For example, an implementation may support the ILP32_OFF32 environment for legacy reasons with a 32-bit time_t, whereas in a conforming environment time_tis required to have a width of at least 64 bits. Application writers should consult an implementation's POSIX Conformance Document for information about the conformance of each supported programming environment.

Cross-volume change to XRAT ...

On page 3519 line 119141 section A.4.16 Seconds Since the Epoch, change:
Implementations that implement time_t as a signed 32-bit integer will overflow in 2038. This standard requires that time_t be an integer type with implementation-defined size, but does not mandate a particular size.
to:
The number of seconds since the epoch overflows a signed 32-bit integer in 2038. This standard requires that time_t is an integer type with a width of at least 64 bits (in conforming programming environments).

Tags No tags attached.
Attached Files

- Relationships

There are no notes attached to this issue.

- Issue History
Date Modified Username Field Change
2021-03-26 15:34 geoffclare New Issue
2021-03-26 15:34 geoffclare Name => Geoff Clare
2021-03-26 15:34 geoffclare Organization => The Open Group
2021-03-26 15:34 geoffclare Section => time()
2021-03-26 15:34 geoffclare Page Number => 2149
2021-03-26 15:34 geoffclare Line Number => 68870
2021-03-26 15:34 geoffclare Interp Status => ---


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker