NetBSD Problem Report #50574
From gson@gson.org Sun Dec 20 18:49:26 2015
Return-Path: <gson@gson.org>
Received: from mail.netbsd.org (mail.NetBSD.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 7D1F67A20D
for <gnats-bugs@gnats.NetBSD.org>; Sun, 20 Dec 2015 18:49:26 +0000 (UTC)
Message-Id: <20151220184918.0705A744712@guava.gson.org>
Date: Sun, 20 Dec 2015 20:49:18 +0200 (EET)
From: gson@gson.org (Andreas Gustafsson)
Reply-To: gson@gson.org (Andreas Gustafsson)
To: gnats-bugs@gnats.NetBSD.org
Subject: lib/libutil/t_parsedate:relative test fails at times
X-Send-Pr-Version: 3.95
>Number: 50574
>Category: bin
>Synopsis: lib/libutil/t_parsedate:relative test fails at times
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: bin-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Sun Dec 20 18:50:00 +0000 2015
>Closed-Date: Wed Mar 22 18:02:48 +0000 2017
>Last-Modified: Wed Mar 22 18:02:48 +0000 2017
>Originator: Andreas Gustafsson
>Release: NetBSD-current as of December 2015
>Organization:
>Environment:
System: NetBSD
Architecture: x86_64
Machine: amd64
>Description:
Looking at the results of past ATF test runs, the "relative" test case
of the lib/libutil/t_parsedate test has been failing in some, but not
all of the runs. The failures do not appear to be random; they
exhibit a pattern where many tests in a row will pass, followed by
many tests that fail. For example, here are the outcomes of the last
100 runs on babylon5.netbsd.org ordered by CVS source date; a dash "-"
means the test passed, and an "X" means it failed:
XX-------------------------XXXXXXXX--XXXX-------------------------XXXXXXXXX---------------XXXXXXXXXX
Since the test involves date processing, I conjecture that the
circumstance that determines whether the test will pass or fail is the
date on which it is run (which is not necessarily the same as the CVS
source date; this may account for the irregularity of the gaps in the
above data).
>How-To-Repeat:
Search for for "relative" in http://releng.netbsd.org/b5reports/i386/commits-2015.12.html .
>Fix:
>Release-Note:
>Audit-Trail:
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/tests/lib/libutil
Date: Thu, 31 Dec 2015 10:10:15 +0000
Module Name: src
Committed By: dholland
Date: Thu Dec 31 10:10:15 UTC 2015
Modified Files:
src/tests/lib/libutil: t_parsedate.c
Log Message:
Fix the "Tuesday midnight" test to match what parsedate.y does; in
particular it doesn't add a week if evaluating that on Wednesday.
Whether that's right is an open question, but there's not exactly a
spec for parsedate.y and there's no point having the test fail one
day in seven.
PR 50574.
To generate a diff of this commit:
cvs rdiff -u -r1.16 -r1.17 src/tests/lib/libutil/t_parsedate.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/tests/lib/libutil
Date: Thu, 31 Dec 2015 10:18:00 +0000
Module Name: src
Committed By: dholland
Date: Thu Dec 31 10:18:00 UTC 2015
Modified Files:
src/tests/lib/libutil: t_parsedate.c
Log Message:
When evaluated on a Sunday, "next Sunday" means 7 days in the future,
not 14. When evaluated on a Monday, it apparently means 13 days in the
future. There's not exactly a spec for parsedate.y, so conform to the
implementation.
PR 50574.
XXX: to me at least this is an odd notion of "next Sunday", but whatever...
To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.18 src/tests/lib/libutil/t_parsedate.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/lib/libutil
Date: Thu, 31 Dec 2015 10:31:07 +0000
Module Name: src
Committed By: dholland
Date: Thu Dec 31 10:31:07 UTC 2015
Modified Files:
src/lib/libutil: parsedate.y
Log Message:
Always use localtime_r; I don't think any of this code is tripping
itself up, but it's still good practice for library functions to not
trash static libc state. Might be relevant to PR 50574.
To generate a diff of this commit:
cvs rdiff -u -r1.25 -r1.26 src/lib/libutil/parsedate.y
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/lib/libutil
Date: Thu, 31 Dec 2015 10:52:06 +0000
Module Name: src
Committed By: dholland
Date: Thu Dec 31 10:52:06 UTC 2015
Modified Files:
src/lib/libutil: parsedate.y
Log Message:
When computing relative months, use mktime() directly and don't call
our Convert(). And check it for failure. This fixes three sets of
problems:
(1) depending on the passed-in value of Timezone it might
disassemble the time in one timezone and reassemble it in
another, causing mysterious offsets of a few hours;
(2) with the previous set of changes to this file, Convert() fails
if it ends up normalizing a date, so e.g. going three months
forward from March 31 would fail;
(3) previously if Convert() failed we passed -1 on to DSTcorrect(),
which made a mess.
PR 50574.
To generate a diff of this commit:
cvs rdiff -u -r1.26 -r1.27 src/lib/libutil/parsedate.y
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: "David A. Holland" <dholland@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/tests/lib/libutil
Date: Thu, 31 Dec 2015 10:56:13 +0000
Module Name: src
Committed By: dholland
Date: Thu Dec 31 10:56:13 UTC 2015
Modified Files:
src/tests/lib/libutil: t_parsedate.c
Log Message:
Fix REL_CHECK error output; it had "expected" and "obtained" swapped.
While here, improve the general legibility of the printout. Not
actually relevant to PR 50574, but anyone looking at that should be
aware of this change.
To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.19 src/tests/lib/libutil/t_parsedate.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: dholland@NetBSD.org
State-Changed-When: Thu, 31 Dec 2015 11:11:23 +0000
State-Changed-Why:
I think that's all the ones in this month's logs. Please crosscheck...
From: Andreas Gustafsson <gson@gson.org>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@netbsd.org,
netbsd-bugs@netbsd.org,
dholland@NetBSD.org,
gson@gson.org (Andreas Gustafsson)
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Thu, 31 Dec 2015 13:24:55 +0200
dholland@NetBSD.org wrote:
> I think that's all the ones in this month's logs. Please crosscheck...
I'll just let the test run for another month and close the PR if there
are no more failures.
--
Andreas Gustafsson, gson@gson.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Thu, 31 Dec 2015 11:42:12 +0000
On Thu, Dec 31, 2015 at 11:30:01AM +0000, Andreas Gustafsson wrote:
> > I think that's all the ones in this month's logs. Please crosscheck...
>
> I'll just let the test run for another month and close the PR if there
> are no more failures.
Ok, sure.
--
David A. Holland
dholland@netbsd.org
From: Andreas Gustafsson <gson@gson.org>
To: dholland@NetBSD.org,
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Fri, 1 Jan 2016 14:54:01 +0200
There's a new failure in
http://releng.netbsd.org/b5reports/i386/build/2015.12.31.20.11.32/test.html#lib_libutil_t_parsedate_relative
with the error message
*** Check failed: /tmp/bracket/build/2015.12.31.20.11.32-i386/src/tests/lib/libutil/t_parsedate.c:341: p != q: From "+6 months 2 days", obtained 1467502383 (Sat Jul 2 23:33:03 2016); expected 1467588783 (Sun Jul 3 23:33:03 2016)
--
Andreas Gustafsson, gson@gson.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Fri, 1 Jan 2016 19:59:08 +0000
On Fri, Jan 01, 2016 at 12:55:00PM +0000, Andreas Gustafsson wrote:
> There's a new failure in
>
> http://releng.netbsd.org/b5reports/i386/build/2015.12.31.20.11.32/test.html#lib_libutil_t_parsedate_relative
>
> with the error message
>
> *** Check failed: /tmp/bracket/build/2015.12.31.20.11.32-i386/src/tests/lib/libutil/t_parsedate.c:341: p != q: From "+6 months 2 days", obtained 1467502383 (Sat Jul 2 23:33:03 2016); expected 1467588783 (Sun Jul 3 23:33:03 2016)
That's an annoying one; it's not even clear what the right answer is.
If it's Dec. 31 and you add six months, that gets June 31, and since
there's no such day it's actually July 1. Then two more days is July
3. But, if you start on Dec. 31 and add two days, that's January 2,
and six months more is July 2. (And the inverse problem occurs on
April 30.)
Suggestions? The code in parsedate.y applies month and day offsets
separately. Maybe it should apply all the offsets and then renormalize
only once? That would at least provide consistent behavior.
--
David A. Holland
dholland@netbsd.org
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sat, 02 Jan 2016 09:22:18 +0700
Date: Fri, 1 Jan 2016 20:00:01 +0000 (UTC)
From: David Holland <dholland-bugs@netbsd.org>
Message-ID: <20160101200001.DD7897ACCC@mollari.NetBSD.org>
I've been away from NetBSD e-mail for a few days (travelling) so I
missed most of this as it was happening...
First, apologies for bugs in the tests (Christos committed them, but
I'm responsible) that were recently added, I thought I had most of
them worked out properly, but obviously not quite all (still, a test that
fails, and can be corrected is probably better than no test at all.)
But the recent changes that made this happen ...
| If it's Dec. 31 and you add six months, that gets June 31, and since
| there's no such day it's actually July 1.
is I think incorrect. It should be (if it is defined at all) June 30.
That is, 6 months from the last day of December is the last day of June.
(If I wanted 181 (or 182 this season) days from Dec 31, that's what I'd say.)
(Three months from Mar 31 is the same, it is not 91 days from Mar 31.)
It only makes a meaningful difference when moving from one of the "excess" days
in a month with more days than the target month, though it would be tempting
to make one month from April 30 be May 31 (sometimes, it depends upon context.)
The same should apply to "ago" - "1 month ago" on Dec 31 should give Nov 30,
not Dec 1.
If it worked that way, it wouldn't matter which order things were added
(I think) though I think I agree it would be better to do all offsets
in one step, then normalise (but that just moves the decision out of
parsedate and into mktime ... somewhere someone still needs to make one
decision first.)
On the "next Sunday" question, I agree, the code as it is now is weird
(I said the same to Christos when we were discussing the tests) - I assumed
it was correct for someone's local usage, so just left it alone. But
perhaps not. I also agree that which Sunday it means depends upon which
day the phrase is uttered, I'd say Mon/Tue/Wed "next Sunday" and "Sunday"
should probably mean the same, on Fri/Sat, "next Sunday" and "Sunday week"
should probably mean the same, on Thu ??? It also depends whether one has
recently used the phrase "this Sunday" or "this coming Sunday" (or even
perhaps just "Sunday" - if so, "next Sunday" generally means the following
one, as in a shorthand for "the next Sunday").
Since parsedate was originally (I believe, Steve Bellovin can correct if
he's still paying attention here) intended for handing the weirdness people
used to put in the Date: header of usenet messages, dealing with specs of
future times was never one of its goals ... that was all added later, and
generally solved whatever need someone had that week...
Using any of this in any way other than "I wonder what parsedate does with..."
is probably not to be recommended.
kre
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sat, 2 Jan 2016 12:15:46 +0100
On Sat, Jan 02, 2016 at 02:25:00AM +0000, Robert Elz wrote:
> Since parsedate was originally (I believe, Steve Bellovin can correct if
> he's still paying attention here) intended for handing the weirdness people
> used to put in the Date: header of usenet messages, dealing with specs of
> future times was never one of its goals ... that was all added later, and
> generally solved whatever need someone had that week...
>
> Using any of this in any way other than "I wonder what parsedate does with..."
> is probably not to be recommended.
I'd argue that all of this should be removed. It is "parsedate" and not
"Siri", "Eliza", or the wolfram alpha interface. IMHO "tomorrow" is not
a date, but "Jan 3, 2016" is - even if both would mean the same to a
human reader today.
If we fear for backward compat, at least document them as deprecated
and disable all tests for them.
Martin
From: christos@zoulas.com (Christos Zoulas)
To: gnats-bugs@NetBSD.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
gson@gson.org (Andreas Gustafsson)
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sat, 2 Jan 2016 10:48:56 -0500
On Jan 2, 11:20am, martin@duskware.de (Martin Husemann) wrote:
-- Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at tim
| I'd argue that all of this should be removed. It is "parsedate" and not
| "Siri", "Eliza", or the wolfram alpha interface. IMHO "tomorrow" is not
| a date, but "Jan 3, 2016" is - even if both would mean the same to a
| human reader today.
|
| If we fear for backward compat, at least document them as deprecated
| and disable all tests for them.
These are used all the time. Haven't you ran cvs -D '-1 week', or
cvs -D yesterday?
christos
From: Martin Husemann <martin@duskware.de>
To: Christos Zoulas <christos@zoulas.com>
Cc: gnats-bugs@NetBSD.org
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sat, 2 Jan 2016 20:00:27 +0100
On Sat, Jan 02, 2016 at 10:48:56AM -0500, Christos Zoulas wrote:
> These are used all the time. Haven't you ran cvs -D '-1 week', or
> cvs -D yesterday?
No, never did that. I do not like programs trying to guess what I mean.
-D "20151226 20:00 UTC" is not a lot more to type and always clearer.
But as it is documented at least for cvs -D and date -d, there is no point
in removing the (mis-)feature.
Martin
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sun, 3 Jan 2016 00:08:59 +0000
On Sat, Jan 02, 2016 at 07:05:01PM +0000, Martin Husemann wrote:
> On Sat, Jan 02, 2016 at 10:48:56AM -0500, Christos Zoulas wrote:
> > These are used all the time. Haven't you ran cvs -D '-1 week', or
> > cvs -D yesterday?
>
> No, never did that. I do not like programs trying to guess what I mean.
> -D "20151226 20:00 UTC" is not a lot more to type and always clearer.
>
> But as it is documented at least for cvs -D and date -d, there is no point
> in removing the (mis-)feature.
My experience over the years has been that the date formats recognized
(and understood) by CVS do not as a general rule match the
documentation, so with the restriction that things like "yesterday"
are effectively required for various CVS purposes I see no harm in
restructuring/changing things if someone can come up with a more
coherent spec.
What uses it besides CVS and date?
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sun, 3 Jan 2016 00:09:57 +0000
On Fri, Jan 01, 2016 at 08:00:01PM +0000, David Holland wrote:
> That's an annoying one; it's not even clear what the right answer is.
Three more or less arbitrarily solicited opinions have unanimously
agreed that the answer should be July 2; that is, parsedate.y is
correct and the test code is wrong.
mktime() is obliged (by longtime convention and maybe standards) to
preserve day counts when normalizing, but it's up to parsedate.y (and
the test code) to decide when and how many times to call mktime to
normalize.
I see three alternatives:
A. Add days in first, normalize, then add months and normalize again.
B. Add months, normalize, then add days and normalize again, or,
equivalently, add months and days and normalize once.
C. Add months, normalize but clamp to the last day to avoid rollover,
then add days and normalize.
These produce the following results in the following corner cases:
A B C
* +6 months 2 days from Dec 31: Jul 2 Jul 3 Jul 2
* -6 months 2 days from Jul 2: Dec 30 Dec 31 Dec 31
* +6m/2d then -6m/2d from Dec 31: Dec 30 Jan 1 Dec 31
* +6 months 2 days from Apr 30: Nov 2 Nov 1 Nov 1
* -6 months 2 days from Nov 2: May 1 Apr 30 Apr 30
* +6m/2d then -6m/2d from Apr 30: May 1 Apr 29 Apr 29
In the case immediately at hand (the first one) method B produces
what's been characterized as the wrong answer, so it's clearly not the
right choice. Method C beats method A on the grounds that adding and
then subtracting the same amount of time yields the same day, but that
only works for Dec 31, not for Apr 30.
To make the Apr 30 case work in this fashion, we need a rule by which
six months from Apr 30 is Oct 31, that is, preserving the number of
days to the end of the month rather than from the beginning, as Robert
Elz hinted at. The problem with this is that then you need to switch
from days-from-start to days-to-end sometime in the middle of the
month and that just moves the behavioral oddities. (One month from
January 16th is... February 15th? 14th?) This doesn't seem like a
winner.
Or maybe instead do the following:
- When adding time, add months first, and normalize preventing
rollover. Then add days and normalize.
- When subtracting time, subtract days first and normalize. Then
subtract months preventing rollover.
That produces these answers:
* +6 months 2 days from Dec 31: Jul 2
* -6 months 2 days from Jul 2: Dec 30
* +6m/2d then -6m/2d from Dec 31: Dec 30
* +6 months 2 days from Apr 30: Nov 1
* -6 months 2 days from Nov 2: Apr 30
* +6m/2d then -6m/2d from Apr 30: Apr 30
but that fixes Apr 30 at the cost of breaking Dec 31, which isn't
actually any better. Feh.
I'm sort of inlined to suggest the following, although it would
require a good bit of hacking on parsedate.y:
- Apply each relative time or date offset in the order given and
normalize after each step.
Then "+6 months 2 days" from Dec 31 would be July 3, or July 2 if we
rule that adding months should never cause a month rollover, but "+2
days 6 months" would be July 2.
--
David A. Holland
dholland@netbsd.org
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Sun, 03 Jan 2016 09:12:47 +0700
Date: Sun, 3 Jan 2016 00:10:01 +0000 (UTC)
From: David Holland <dholland-bugs@netbsd.org>
Message-ID: <20160103001002.02F277ABF4@mollari.NetBSD.org>
| The problem with this is that then you need to switch
| from days-from-start to days-to-end sometime in the middle of the
| month and that just moves the behavioral oddities. (One month from
| January 16th is... February 15th? 14th?) This doesn't seem like a
| winner.
No, it wouldn't be, but "sometime in the middle of the month" should be
treated as "when the day in question does not exist in one of the months"
(1 month forward from anymonth-but-january the 30th is always the 30th of
the following month, that is, 1 month from June 30 is not July 31, ever,
even though 1 month ago from July 31 should be june 30). That those are
not inverses is just another property of the wacky calendaring system that
has developed through time. We cannot fix that and should not try.
| I'm sort of inlined to suggest the following, although it would
| require a good bit of hacking on parsedate.y:
If we can agree on what the various words should mean, and how things
should be interpreted, I'm willing to do the required hacking (and I've
even learned just barely enough about the ATF stuff that I think I can
write tests....)
It might be better though to leave parsedate for external apps that need
it, and write a spec for a replacement function that fixes the other issues
(becoming fully threat safe - though your recent changes probably help there
already, and using timespec's instead of time_t's so fractional seconds
can be supported).
The few NetBSD progs that use parsedate(3) could easily be updated (in
addition to cvs and date, there are also touch(1) and eeprom(8) that I
know of, but a grep to find everything would not be hard) and doing it
this way avoids potentially breaking external code that (for whatever
weird reason) understands how to use parsedate and depends upon its
weirdness.
kre
From: dieter roelants <dieter.NetBSD@pandora.be>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at
times)
Date: Sun, 3 Jan 2016 14:17:41 +0100
On Sun, 3 Jan 2016 00:10:01 +0000 (UTC)
David Holland <dholland-bugs@netbsd.org> wrote:
> My experience over the years has been that the date formats recognized
> (and understood) by CVS do not as a general rule match the
> documentation, so with the restriction that things like "yesterday"
> are effectively required for various CVS purposes I see no harm in
> restructuring/changing things if someone can come up with a more
> coherent spec.
>
> What uses it besides CVS and date?
touch(1), makefs(8)
FWIW, I think it also unlikely somebody or something relies on the
current behaviour of x months + y days.
>
> --
> David A. Holland
> dholland@netbsd.org
>
State-Changed-From-To: feedback->closed
State-Changed-By: gson@NetBSD.org
State-Changed-When: Tue, 02 Feb 2016 08:47:26 +0000
State-Changed-Why:
No failures for a month in the babylon5 i386 test runs.
From: "Andreas Gustafsson" <gson@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/tests/lib/libutil
Date: Sun, 1 May 2016 16:39:47 +0000
Module Name: src
Committed By: gson
Date: Sun May 1 16:39:47 UTC 2016
Modified Files:
src/tests/lib/libutil: t_parsedate.c
Log Message:
In the "relative" test case, run the tests multiple times relative to
various dates over a span of a few decades, instead of just once
relative to the current date. This makes the test fail consistently
instead of sometimes failing and sometimes not depending on when
it is run. Makes PR lib/50574 consistently reproducible.
To generate a diff of this commit:
cvs rdiff -u -r1.19 -r1.20 src/tests/lib/libutil/t_parsedate.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: closed->open
State-Changed-By: gson@NetBSD.org
State-Changed-When: Sun, 01 May 2016 16:42:53 +0000
State-Changed-Why:
The problem has recurred, and the test now reproduces it consistently.
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)
Date: Mon, 02 May 2016 14:06:55 +0700
Date: Sun, 1 May 2016 16:42:54 +0000 (UTC)
From: gson@NetBSD.org
Message-ID: <20160501164254.2CA347A64F@mollari.NetBSD.org>
| The problem has recurred, and the test now reproduces it consistently.
I think I have some patches (for parsedate, and the tests) that
will make the tests work, and parsedate a little more rational in
some cases (and also a little more flexible, though probably not
in ways anyone will notice, I expect.)
I am testing now (well, building so I can test.) After I have
verified success (or fixed whatever is not successful) I will
send patches.
One thing I have not yet done, but am seriously considering, is
changing "next" from 2 to 1. To understand what this means it
is necessary first to understand that in parsedate, everything
(except fillers, like spaces, and colons, etc) is a scaled typed number.
The types are things like "relative seconds", "absolute day", ...
"next" is simply "2" (an ordinary integer) (for comparison, "this" is 0,
and "last" is -1).
That's because even though it might make sense (today, Monday May 2) for
"next Tuesday" to be Tuesday May 10 (rather than tomorrow, May 3),
it makes very little sense for "next year" to be May 2, 2018 (which is
how it is currently interpreted - that is, effectively, "+ 2 year".
[Aside: this parsig method has some strange artifacts, "next yesterday"
means "2 days ago" because "next" is 2, and "yesterday is "-1 day", and
adjacent numbers are multiplied, similarly "last yesterday" is the same
as "tomorrow" (-1 * -1 day == +1 day).]
The downside of the change wold be that "next Monday" (uttered today)
would become Mon May 2 (ie: today), which is rarely what is intended,
whereas as things are now, it means Mon May 9 (same as 2 Monday).
Getting all of this "right" would mean huge changes to the (very simple)
parser that is parsedate, and complicate it greatly. So I am seeking
opinions on which is more important to work naturally, and until we
work out what "next xxx" really should mean, I will not change it.
kre
From: "Robert Elz" <kre@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/50574 CVS commit: src/tests/lib/libutil
Date: Tue, 3 May 2016 18:18:15 +0000
Module Name: src
Committed By: kre
Date: Tue May 3 18:18:15 UTC 2016
Modified Files:
src/tests/lib/libutil: t_parsedate.c
Log Message:
PR bin/50574 - make the tests conform to what parsedate() actually
does, so they should no longer fail. This needs parsedate.y 1.28
in order to work properly.
OK christos@
To generate a diff of this commit:
cvs rdiff -u -r1.21 -r1.22 src/tests/lib/libutil/t_parsedate.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->feedback
State-Changed-By: kre@NetBSD.org
State-Changed-When: Tue, 21 Mar 2017 18:30:22 +0000
State-Changed-Why:
Are you happy that this is fixed? (If so you can just close it...)
State-Changed-From-To: feedback->closed
State-Changed-By: gson@NetBSD.org
State-Changed-When: Wed, 22 Mar 2017 18:02:48 +0000
State-Changed-Why:
Tests pass, I'm happy it's fixed.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home