Re: [lmi] Creating end-user packages for msw

[Greg Chicares]

On 2010-03-22 18:26Z, Murphy, Kimberly wrote:
> Greg Chicares wrote:
[...]
>> We could override $fardel_date_script if we want a different outcome
>> than the default provided, or change it if that's not an appropriate
>> default.
> 
> The first of a given month is appropriate for most end-user 
> packages. On occasion, some end-users are provided the system 
> a few days earlier. Waiting until the first of the month may 
> not be a hardship in most situations, unless of course there's 
> a feature someone wants to get their hands on. In this case, 
> the 'fardel_date_script' could be overridden.

Okay, that's an important point. We need to be able to distribute
off-cycle releases to fix critical defects or to add significant
features. In that case, the begin-date would be the current date,
and the end-date would be the same as usual.

Are there other cases that we should automate? I know we once
prepared a distribution with an end-date far into the future, but
that was one time only, for 7702A testing against an admin system,
for one person...who actually never used it. Yet that contravenes
a compliance safeguard, so I'm not sure we should make it easy.

If there's no other special case, then we have a boolean choice
between exactly two behaviors. If so, then I hesitate to offer
begin-date and end-date as customization points. Any potential
increase in complexity aside, the danger is that someone someday
will start overriding both dates every month. Obviously you
wouldn't, but your successor might; and monthly manual overrides
introduce a likelihood of human error.

> Converting the default beginning date in the fardel_date_script 
> to Julian date, I get:
> 
>   The Julian date for CE  2010 April  1 00:00:00.0 UT is
>   JD 2455287.50000
> 
> However, if I was to manually enter the date in the expiry, 
> I would enter a Julian date of:
> 
>   The Julian date for CE  2010 April  1 12:00:00.0 UT is
>   JD 2455288.00000

I believe authentication uses only the calendar date in the local
timezone, without regard to the time of day. It should succeed
from the first moment of the first day (because end users may be
running illustrations one minute after midnight) through the
last moment on the last day (so they can run illustrations one
minute before midnight). I'm not sure whether the defaults in
'workhorse.make' do exactly that, but I'm pretty sure it's based
on local time rather than UTC.

> The end date for all packages is the first of the following 
> month at midnight, and manually entered would be:
> 
>   The Julian date for CE  2010 May  1 12:00:00.0 UT is
>   JD 2455318.00000
> 
> while the script generates:
> 
>   The Julian date for CE  2010 April 30 00:00:00.0 UT is
>   JD 2455316.50000

I would guess that the beginning and ending JDN both get
converted to integer when they're read from 'expiry'.

The test in 'authenticity.cpp' looks like this:

    [candidate = current local date]
    // Make sure candidate date is within valid range.
    if(candidate < begin)
      reject
    if(end <= candidate)
      reject

which leads me to guess that the specifying the first and last
days of a month in 'expiry' would give the desired behavior.
But the easiest way to find out for sure is to test it.