Thanks for the report.
Lars Hecking <[EMAIL PROTECTED]> writes:
| Versions affected: 1.16, 2.0, all older versions probably too
| Platforms tested: RedHat Linux 6.1, Tru64 4.0F, Solaris 7, IRIX 6.3
| Platforms affected: probably all
|
| (1) $ date 0107115768
| date: invalid date `0107115768'
That is interpreted like
(1) $ date 010711572068
and as you noted, any date past 2038 is invalid for platforms
with 32-bit time_t.
So I don't think it is a bug.
| (2) $ date 010711571968
| date: cannot set date: Not owner
| Sun Jan 7 11:57:00 GMT 1968
|
| (3) $ date 010711572068
| date: invalid date `010711572068'
|
| Two-digit years 00-38 are accepted as 20xx, 69-99 are accepted as 19xx,
| ok [case (2)]. But why are 39-68 rejected as invalid [case (1)]?. This
| behaviour does not quite follow the Open Group recommendations wrt the
| Single Unix(R) Specification.
If you still think GNU date (from sh-utils-2.0 or newer) is wrong, please
refer me to the exact wording that encourages a different implementation.
The existing implementation (lib/posixtm.c) includes this comment and code:
/* Deduce the century based on the year.
See POSIX.2 section 4.63.3. */
if (digit_pair[0] <= 68)
t.tm_year += 100;
| http://www.UNIX-systems.org/version2/whatsnew/year2000.html
|
| As for dates > '03:14:07 19 jan 2038' [case (3)], the behaviour is probably
| correct (implementation defined) for platforms with 32 bit time_t.
