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: 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@localhost>
     Message-ID:  <20160103001002.02F277ABF4%mollari.NetBSD.org@localhost>
 
   | 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