Re: parse-duration.c - TIME_MAX 2038 unpreparedness

[Bruce Korb]

On 06/01/14 10:04, Jonas 'Sortie' Termansen wrote:
> Hi,
>
> I noticed that lib/parse-duration.c does:
>
> #define TIME_MAX 0x7FFFFFFF
>
> This is naturally entirely unacceptable as the 2038 bug ((time_t)
> INT32_MAX) is coming up soon

OK, I promise to fix it within the next 24 years.

In truth, since this is a _duration_, it really constrains the
result to be within 68 years.  I did actually think about it
for a few moments and decided a rigorous solution didn't warrant
the effort.

> It would probably be best to not use a define named TIME_MAX, as that
> name would be ideal if a standard header wanted to expose the domain of
> time_t for use in cases like this (indeed, this came up because I am
> adding a TIME_MAX constant to my libc).

I also Googled for a POSIX "It's mine and you can't have it" statement
for the value name and got no results.  I do kind-of like the DEC
regime of prefixing values with "SYS$", but that is another world.
Since that value is used internally, I'll just prefix it with:

  #undef TIME_MAX

and document the "constraint" that time differences beyond 68 years
are not supported.

Or maybe:

#ifdef TIME_MAX
#define TIME_LIMIT TIME_MAX
#else
#define TIME_LIMIT (((time_t)~0) >> 1)
#endif

But I really think 68 years will cover the need. :)

Cheers - Bruce