Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Dec 16, 1:20pm, Mouse wrote: } } >> 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. } > I'm not sure why anyone thinks that ship didn't sail years ago. } } > % cal 6 1942 } } How is that relevant to

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

>> 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. > I'm not sure why anyone thinks that ship didn't sail years ago. > % cal 6 1942 How is that relevant to time_t? I don't think anyone is arguing that programs

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Thu, Dec 13, 2018 at 12:06:04PM +0100, Martin Husemann wrote: > > > 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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Sat, Dec 15, 2018, 1:17 PM Mouse > Might I suggest that the obvious solution to this, and probably a > > host of other issues, is to make time_t an always negative number > > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, > > 19 January 2038, > > While it's academic as

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> Might I suggest that the obvious solution to this, and probably a > host of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, > 19 January 2038, While it's academic as far as this thread is concerned, you can get

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> Date: Sat, 15 Dec 2018 10:30:13 +0100 > From: theo4...@borm.org > > Might I suggest that the obvious solution to this, and probably a host > of other issues, is to make time_t an always negative number > (negint/neglong?) and redefine the epoch as 03:14:09 UTC on Tuesday, 19 > January 2038,

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On 12/12/18 8:46 PM, Michał Górny wrote: Hi, 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. For

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Dec 14, 2:38pm, wrote: } > On Dec 14, 2018, at 9:30 AM, Joerg Sonnenberger wrote: } > On Thu, Dec 13, 2018 at 02:37:06AM +0100, Kamil Rytarowski wrote: } >> In real life it's often needed to store time_t pointing before the UNIX } >> epoch. } > } > Again, I quite disagree and believe that

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 14, 2018, at 9:30 AM, Joerg Sonnenberger wrote: > > > [EXTERNAL EMAIL] > > On Thu, Dec 13, 2018 at 02:37:06AM +0100, Kamil Rytarowski wrote: >> In real life it's often needed to store time_t pointing before the UNIX >> epoch. > > Again, I quite disagree and believe that you are

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Thu, Dec 13, 2018 at 02:37:06AM +0100, Kamil Rytarowski wrote: > In real life it's often needed to store time_t pointing before the UNIX > epoch. Again, I quite disagree and believe that you are confusing two different things. It makes perfect sense in certain applications to store time as

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

mo...@rodents-montreal.org (Mouse) writes: >So, what type _should_ be used for it? double or not. -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Thu, Dec 13, 2018, 9:41 AM > > > On Dec 13, 2018, at 6:06 AM, Martin Husemann wrote: > > > > > > [EXTERNAL EMAIL] > > > > On Thu, Dec 13, 2018 at 03:29:03AM +, David Holland wrote: > >> On Wed, Dec 12, 2018 at 10:27:04PM +0100, Joerg Sonnenberger wrote: > >>> On Wed, Dec 12, 2018 at

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 13, 2018, at 6:06 AM, Martin Husemann wrote: > > > [EXTERNAL EMAIL] > > On Thu, Dec 13, 2018 at 03:29:03AM +, 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:

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

The difference between times is an interval, or duration, not a time, and should not be stored in a time_t, ever. So, what type _should_ be used for it? 7.27.2.2 Thedifftime function Synopsis #include double difftime(time_t time1, time_t time0); Description The difftime function

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

>> time_t is signed so that it can also be used to store time >> differences. > That is the thinking that leads to bugs ... it is just the same as > believeing that differences between pointers is a pointer. Or that the difference between two ints is an int. > The difference between times is an

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Thu, Dec 13, 2018 at 03:29:03AM +, 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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On 12.12.2018 23:06, Warner Losh wrote: > > > On Wed, Dec 12, 2018 at 2:34 PM 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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

Date:Thu, 13 Dec 2018 07:16:32 - (UTC) From:mlel...@serpens.de (Michael van Elst) Message-ID: | time_t is signed so that it can also be used to store time differences. That is the thinking that leads to bugs ... it is just the same as believeing that

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Wed, Dec 12, 2018 at 2:34 PM 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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

n...@gmx.com (Kamil Rytarowski) writes: >I disagree, this used to be a flaw in C/POSIX interface to keep one >specific point of time invalid. It should be fixed similarly to other OSe= >s. negative time_t values don't specify a point in time. The talk about "one specific point of time invalid"

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

Date:Thu, 13 Dec 2018 03:55:12 +0100 From:Kamil Rytarowski Message-ID: <70762ce1-90e5-eb8e-acc0-6f4d9a581...@gmx.com> | Storing negative times is a generic open topic so I defer myself from | discussing it. It is, and I agree, it is pointless. | It's the

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On Wed, Dec 12, 2018 at 08:46:33PM +0100, Micha? G?rny wrote: > Sadly, this does not solve the problem entirely since kernel also > special-cases the value of '-1'. FWICS, the vattr structure used to > update filesystem information uses the value of VNOVAL or -1 to indicate > that the

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On 13.12.2018 03:22, Mouse wrote: >> In real life it's often needed to store time_t pointing before the >> UNIX epoch. > > I am inclined to doubt it - "real life" needs to store such times, > certainly, but I have yet to see a case where it imposes any particular > representation for that

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> In real life it's often needed to store time_t pointing before the > UNIX epoch. I am inclined to doubt it - "real life" needs to store such times, certainly, but I have yet to see a case where it imposes any particular representation for that storage. (Without enlarging time_t, you can't go

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

On 12.12.2018 22:27, 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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

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

Re: Support for tv_sec=-1 (one second before the epoch) timestamps?

> On Dec 12, 2018, at 11:46 AM, Michał Górny wrote: > > c. Add an extra flag to va_vaflags that explicitly indicates timestamps > are supposed to be changed; always ignore tv_sec when it's unset, > otherwise respect tv_sec independently of value. This is part of a bigger problem with how the