> On Dec 13, 2018, at 6:06 AM, Martin Husemann <martin%duskware.de@localhost> wrote:
>
>
> [EXTERNAL EMAIL]
>
> On Thu, Dec 13, 2018 at 03:29:03AM +0000, David Holland wrote:
>> On Wed, Dec 12, 2018 at 10:27:04PM +0100, Joerg Sonnenberger wrote:
>>> On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote:
>>>> While researching libc++ test failures, I've discovered that NetBSD
>>>> suffers from the same issue as FreeBSD -- that is, both the userspace
>>>> tooling and the kernel have problems with (time_t)-1 timestamp,
>>>> i.e. one second before the epoch.
>>>
>>> I see no reason why that should be valid or more general, why any
>>> negative value of time_t is required to be valid.
>>
>> Are you Dan Pop? :-)
>
> Not sure about that, but I agree that we should not extend the range of
> time_t (aka "seconds since the epoch") to negative values. It is a pandora
> box, keep it closed.
>
> Martin
You could certainly make that restriction. On the other hand, the TZ project maintains timezone offset rules for times long before the epoch. Those time stamps, and the rules for processing them, are well defined. At least until you get far enough back that Gregorian vs. Julian calendar becomes a consideration.
Doesn't matter. The meaning of negative time_t values is implementation defined. Some implementations have it well defined, but there are problems due to things like the return value of time(). Is it convenient for values before the epoch to be well defined? Sure. But it's not required by the standards. I would posit that makes the specific test that kicked off this thread invalid.
Warner