svn commit: r272562 - head/lib/libc/stdtime

[Andrey Chernov]

On 07.10.2014 2:45, Ian Lepore wrote:
> Using -1 as an error indicator in time conversions has drawbacks (your
> change doesn't make it any better or worse, I'm just whining in
> general)...
> 
>         revolution > date -ujf "%Y-%m-%dT%H:%M:%S" +%s 1970-01-01T0:0:0
>         0
>         revolution > date -ujf "%Y-%m-%dT%H:%M:%S" +%s 1969-12-31T23:59:58
>         -2
>         revolution > date -ujf "%Y-%m-%dT%H:%M:%S" +%s 1969-12-31T23:59:59
>         date: nonexistent time
> 
> If timegm() and mktime() were to set errno in addition to returning -1,
> strptime() (and others) could use that to see the difference between
> errors and the second immediately before the epoch.  I'm not sure of the
> standards-related implications of those routines setting errno though.

POSIX, Base Specs, Issue 7, mktime says:
"If the time since the Epoch cannot be represented, the function shall
return the value (time_t)−1 and set errno to indicate the error.
...
[EOVERFLOW] The result cannot be represented."

But we don't set EOVERFLOW inside timegm or mktime...

About negative time_t values, POSIX, Seconds Since the Epoch, says:
"...is related to a time represented as seconds since the Epoch...
If the year is <1970 or the value is negative, the relationship is
undefined."

So, we are free to either treat all negative values as errors or set
EOVERFLOW in our time functions and add a check to every lib & program
since nobody checks it.

I'll think about this place more..

-- 
http://ache.vniz.net/