View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001066 | 1003.1(2013)/Issue7+TC1 | Base Definitions and Headers | public | 2016-08-11 03:22 | 2016-08-12 01:19 |
| Reporter | dannyniu | Assigned To | |||
| Priority | normal | Severity | Editorial | Type | Enhancement Request |
| Status | Closed | Resolution | Withdrawn | ||
| Name | DannyNiu/NJF | ||||
| Organization | |||||
| User Reference | |||||
| Section | Base Definition. 8.3 Other Environment Variables | ||||
| Page Number | New | ||||
| Line Number | New | ||||
| Interp Status | --- | ||||
| Final Accepted Text | |||||
| Summary | 0001066: Solution proposal to the 2038 problem. | ||||
| Description | The 2038 problem is the wide known problem within the representation of time in Unix. A 32-bit signed time_t value will overflow at sometime in the year 2038. Although in POSIX, epoch is defined as 1970, the representation of time_t in the C language is implementation-defined. I thought to myself, maybe we can utilize this loophole to our aid in solving the 2038 problem. We add a environment variable POSIX_EPOCH to indicate the year, of which it's 0:00 am Jan 1st will be used as epoch in system internal representation of time_t, and recommend against using time_t for interchange. | ||||
| Desired Action | Add a paragraph to section 8.3.: <dl> <dt>POSIX_EPOCH</dt> <dd>Selects a year as the year of epoch for the internal representation of time_t. This variable may require appropriate privilege to set, and changing it during the run of application may result in undefined behavior. This variable need not to be system-wide. </dd> </dl> | ||||
| Tags | No tags attached. | ||||
|
|
This does not work, as POSIX requires some programs to work with dates between 1969 and 2068. There is however an already working and implemented solution that folds the time between 0x80000000 (1901 Dec 13 20:45:52) and 0xBA37E000 (1932 Nov 25 17:31:44) to 2038 ... 2069 Jan 1 00:00:00 |
|
|
Is the 2038 problem still an actual problem? I beg to differ. Most operating systems have already switched over to using a 64-bits time_t in one way or another. - Some systems started using it for all new hardware architectures. FreeBSD only uses a 32-bits time_t on powerpc32 and i386. - Other systems changed the ABI to use a 64-bits time_t in one go. OpenBSD, for example. The Linux folks are also tackling this problem by adding extra system calls, letting the C library do the remapping, etc: https://lwn.net/Articles/599580/ |
|
|
Before I send a warning, FreeBSD was planning to create their first 64 bit platform with a 32 bit time_t Now they recently decided to create something that even breaks binary compatibility, but this is OK for the FreeBSD people. There are however platforms that like to retain binary compatibility and they would need to introduce some tricks. The modifications I mentioned may be implemented on top of the existing libc. BTW: the mistake happened in 1995, when time_t was forgotten on the large file summit. |
|
|
Binary compatibility is not just the size of the types, but also the behavior. If I understand correctly, the tricks you mentioned change the behavior of applications that would deal with dates before 25 Nov 1932. This may not be common, but I would not say that binary compatibility is retained with these tricks. |
|
|
A fellow mentioned to me that if I want to propose an idea, I have to demonstrate it working; and my proposal cannot work with some existing timestamp data. Therefore I'm pulling my proposal right now. Furthermore, there's example on FreeBSD docs on how to obtain current time from time servers (interprocess communication section). If apps really need accurate time that does not have the pitfall of overflowing, it can be consulted. |
|
|
Withdrawn as requested by submitter in 0001066:0003350. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-08-11 03:22 | dannyniu | New Issue | |
| 2016-08-11 03:22 | dannyniu | Name | => DannyNiu/NJF |
| 2016-08-11 03:22 | dannyniu | Section | => Base Definition. 8.3 Other Environment Variables |
| 2016-08-11 03:22 | dannyniu | Page Number | => New |
| 2016-08-11 03:22 | dannyniu | Line Number | => New |
| 2016-08-11 09:30 | joerg | Note Added: 0003331 | |
| 2016-08-11 09:31 | joerg | Note Edited: 0003331 | |
| 2016-08-11 10:01 | EdSchouten | Note Added: 0003332 | |
| 2016-08-11 10:23 | joerg | Note Added: 0003333 | |
| 2016-08-11 20:41 | Vincent Lefevre | Note Added: 0003344 | |
| 2016-08-12 01:06 | dannyniu | Note Added: 0003350 | |
| 2016-08-12 01:07 | dannyniu | Note Edited: 0003350 | |
| 2016-08-12 01:19 | Don Cragun | Interp Status | => --- |
| 2016-08-12 01:19 | Don Cragun | Note Added: 0003351 | |
| 2016-08-12 01:19 | Don Cragun | Status | New => Closed |
| 2016-08-12 01:19 | Don Cragun | Resolution | Open => Withdrawn |
