Re: [lmi] wx_test_expiry_dates.cpp

[Greg Chicares]

On 2014-12-13 13:41, Vadim Zeitlin wrote:
> On Fri, 12 Dec 2014 20:45:02 +0000 Greg Chicares <address@hidden> wrote:

[...To test 'expiry' before the effective date of a distribution that's
being prepared, as well as to run certain exceptional cases as of a date
in the past...]

> GC> [...] we've altered the computer's clock. That is
> GC> effective, but extremely distasteful; and someday the corporation may
> GC> withdraw the privilege to do that, so that's not acceptable either.
> GC> 
> GC> The best solution we see, which we would like to ask you to implement
> GC> if you see no better solution,
> 
>  I do see something that looks like a better solution to me: changing the
> system clock is indeed somewhat unappetizing, but the basic idea is sound,
> it's just that using a global solution to a local problem[*] is bad. But
> what if instead of changing the date globally for the entire system, we
> just changed the date used by lmi in authenticate_system()? AFAICS this
> would solve the problem nicely: we'd still run exactly the same code, so no
> divergences from the real program behaviour would be possible, and all Kim
> would need to do would be to run the test with --distribution=20150101
> instead of just --distribution option. What do you think?

AIUI, this would have essentially the same effect as what I had proposed:
okay so far.

>  Of course, this would still require some changes to lmi itself, but they
> would be pretty minimal and smaller than what would be needed for your
> solution.
> 
>  Notice that if you really want this functionality to be available at the
> level of the main program itself, and not just in the test, then I still
> think it would be better to add --check-date=YYYYMMDD option to the main
> program rather than specific --warn-about-expiration-but-not-really one you
> proposed. But such option wouldn't be without danger, of course.

Yes. This lets us run exceptional cases as of a date in the past, which is
desirable, so it's preferable to an approach that affects only 'wx_test'.
It's a better solution to that production problem than turning back the
computer's clock.

>  Finally, there is also a possibility to be more general and add a way (via
> command line option or configurable settings value) to change the value of
> "today" in lmi globally. This is more than what's needed just to solve the
> problem at hand but it might be useful, e.g. to test whether lmi suffers
> from y2038k problem. In this case it should be probably called --run-date
> and change the value returned by calendar_date::today() and
> iso_8601_datestamp_verbose_xxx() functions (which don't use calendar_date
> for some reason, perhaps this should be changed?).

Let's not do this. It would take more time than I can allot to satisfy
myself that it's completely correct.

We can test for the y2038 problem by resetting the clock.

The separation between calendar_date and the iso_8601 functions is
deliberate: the latter require use only a standard libc, IIRC. When I
originally wrote them, I was answering beginners' programming questions
in usenet or on mailing lists, and they gave me handy snippets that I
could cut and paste; I might want to use them as a snippet source again,
even if not for usenet. Instead of having them call into calendar_date,
I'd be inclined to add another function to 'miscellany.?pp' to provide
today's date to calendar_date; but that would add a dependency to
calendar_date, though that wouldn't be too terrible. But then how can
we be sure we've intercepted every means by which lmi knows today's
date? And what about PDF files, which are created by an external
program? And...what further questions haven't I had the imagination
to ask? Already I'm spending more time than I can on this just by
writing this paragraph.

> GC> is to add a command-line option to lmi itself that conditionally
> GC> demotes the fatal error to a dire warning.
> 
>  I dislike this solution because I believe a fatal error should always be
> fatal, the code and the behaviour of the program becomes confusing
> otherwise. Running the check at a date at which it's really supposed to be
> used to avoid the error in the first place is much better IMHO.

Okay, we're left with two proposals, which use some command-line option to:
 - demote the fatal error; or
 - change the date used for validation.
I don't feel quite as strongly as you do about the first, but your argument
is strong enough, so I'll accept it and dismiss the first option. As for
the second, you suggested
  --check-date=YYYYMMDD
and I think you'd accept this renaming
  --prospicience=YYYYMMDD
because I'm now very attached to that word. Now, I had originally suggested
  --pyx=prospicience
where 'pyx' doesn't matter too much and the only significant difference
remaining in our command-line options is whether a date is to be specified.
To use my original syntax with the effect you proposed would require us to
read 'expiry' and choose any date within its range for YYYYMMDD. Hmmm....

Requiring a date on the command line makes this facility harder to use.
But that's okay, and even desirable: we want it to be hard to misuse.
We want its use to be possible only as a deliberate, mindful act. So let's
do it your way, but flatter my vanity with s/check-date/prospicience/, okay?

What this means for Kim (and any end user to whom we entrust this secret
facility) is that an archived distribution for June 2014 only could be
used today with '--prospicience=20140613' e.g.; I think she'll accept that,
especially because it requires any user to demonstrate conscious intent by
choosing the date to specify. It can't be used by accident. If it's used,
the user can't claim ignorance: "willful blindness" is ruled out.

Let's not gild the lily by accepting any of the weird formats that are
recognized by /bin/date ; let's just require "date -u +'%Y%m%d'", i.e.,
20141214.