Re: bin/50574 (lib/libutil/t_parsedate:relative test fails at times)

[Robert Elz <kre%munnari.OZ.AU@localhost>]

The following reply was made to PR bin/50574; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: gnats-bugs%NetBSD.org@localhost
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@localhost>
     Message-ID:  <20160101200001.DD7897ACCC%mollari.NetBSD.org@localhost>
 
 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