From 4af94291ae81fbd700b7be2040d4d7866f5ab425 Mon Sep 17 00:00:00 2001 From: Michael Kerrisk Date: Thu, 17 Dec 2015 06:38:14 +0100 Subject: [PATCH] time.2: Describe EOVERFLOW details Heavily based on text proposed by Paul Eggert. Cowritten-by: Paul Eggert Signed-off-by: Michael Kerrisk --- man2/time.2 | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/man2/time.2 b/man2/time.2 index 29a04030a..84d927f82 100644 --- a/man2/time.2 +++ b/man2/time.2 @@ -82,6 +82,27 @@ and the Epoch, because of leap seconds and because system clocks are not required to be synchronized to a standard reference. The intention is that the interpretation of seconds since the Epoch values be consistent; see POSIX.1-2008 Rationale A.4.15 for further rationale. + +On Linux, a call to +.BR time () +with +.I t +specified as NULL cannot fail with the error +.BR EOVERFLOW , +even on ABIs where +.I time_t +is a signed 32-bit integer and the clock ticks past the time 2**31 +(2038-01-19 03:14:08 UTC, ignoring leap seconds). +(POSIX.1 permits, but does not require, the +.B EOVERFLOW +error in the case where the seconds since the Epoch will not fit in +.IR time_t .) +Instead, the behavior on Linux is undefined when the system time is out of the +.I time_t +range. +Applications intended to run after 2038 should use ABIs with +.I time_t +wider than 32 bits. .SH BUGS Error returns from this system call are indistinguishable from successful reports that the time is a few seconds