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

[Vadim Zeitlin]

On Thu, 13 May 2010 15:07:18 -0400 "Murphy, Kimberly" <address@hidden> wrote:

MK> > I believe authentication uses only the calendar date in the local
MK> > timezone, without regard to the time of day. It should succeed
MK> > from the first moment of the first day (because end users may be
MK> > running illustrations one minute after midnight) through the
MK> > last moment on the last day (so they can run illustrations one
MK> > minute before midnight). I'm not sure whether the defaults in
MK> > 'workhorse.make' do exactly that, but I'm pretty sure it's based
MK> > on local time rather than UTC.
MK> 
MK> It is based on local time. The default dates in 'workhorse.make' 
MK> aren't ideal for our end-user packages. For example, let's assume 
MK> today, 2010-05-13, we're packaging the month-end release for use 
MK> on June 1st. I run 'make fardel' and a 'lmi-20100513T1306Z' package 
MK> is produced with an expiry of:
MK> 
MK> 2455329 2455377
MK> 
MK> which coverts to:
MK> 
MK> JD 2455329.00000 is
MK> CE 2010 May 12 12:00:00.0 UT  Wednesday
MK> 
MK> and
MK> 
MK> JD 2455377.00000 is
MK> CE 2010 June 29 12:00:00.0 UT  Tuesday
MK> 
MK> Had this been the actual day the release was created, the dates 
MK> would be incorrect. The begin-date is too early and the end-date 
MK> is too soon.

 I think both dates are too early simply because the offset 2440587 used in
workhorse.make is off by 1. This JDN corresponds to 1969-12-31 date and not
1970-01-01 as I'd expect and as the number of seconds returned by +%s
format specifier of date(1) counts from the latter date ("Unix Epoch"), the
result is one day too early. So I think we should simply use 2440588
instead.

 But even with this adjustment, the end date would still be June 30 and not
July 1. And as the code checks for "end <= current date" it really should
be the latter to behave as explained in the quoted paragraph of Greg's
email above. Of course, fixing this is pretty easy as well if this is what
we need: just remove the "- 1 day" from the assignment to d2.

MK> The actual expiry entered manually would be:
MK> 
MK> 2455349 2455379

 If we need the begin date to be the first of the following month instead
of the current date we should additionally remove the second assignment to
d1 in workhorse.make and use the first one, with "+ 1 month".

MK> > The test in 'authenticity.cpp' looks like this:
MK> > 
MK> >     [candidate = current local date]
MK> >     // Make sure candidate date is within valid range.
MK> >     if(candidate < begin)
MK> >       reject
MK> >     if(end <= candidate)
MK> >       reject
MK> > 
MK> > which leads me to guess that the specifying the first and last
MK> > days of a month in 'expiry' would give the desired behavior.
MK> > But the easiest way to find out for sure is to test it.
MK> 
MK> I agree it does sound as if it would give the behavior we 
MK> want. Entering the first and last days of the month:
MK> 
MK> 2010 May 1 00:00:00 UT
MK> 2010 May 31 00:00:00 UT
MK> 
MK> in the expiry like this,:
MK> 
MK> 2455317.5 2455347.5
MK> 
MK> generates this error when launching Lmi:
MK> 
MK> ---------------------------
MK> Error
MK> ---------------------------
MK> Untimely warning:
MK> Error reading expiry file 'C:/opt/lmi/data/expiry'. 
MK> Try reinstalling.
MK> [file /opt/lmi/src/lmi/authenticity.cpp, line 287]

 That's because the code only supports the entire JDNs probably.

MK> Ultimately, I fixed the expiry dates in 'workhorse.make' to align 
MK> with the current practice for end-user packages:
MK> 
MK> /opt/lmi/src/lmi[0]$diff -U 3 workhorse.make_DEFAULT workhorse.make
MK> --- workhorse.make_DEFAULT      2010-04-22 11:29:44.513212000 -0400
MK> +++ workhorse.make      2010-05-13 09:41:32.000000000 -0400
MK> @@ -924,9 +924,8 @@
MK> 
MK>  fardel_date_script := \
MK>    d0=`$(DATE) +%Y-%m-01`; \
MK> -  d1=`$(DATE) --utc --date="$$d0 + 1 month         " +%s`; \
MK> -  d1=`$(DATE) --utc +%s`; \
MK> -  d2=`$(DATE) --utc --date="$$d0 + 2 months - 1 day" +%s`; \
MK> +  d1=`$(DATE) --utc --date="$$d0 + 1 month + 1 day      " +%s`; \
MK> +  d2=`$(DATE) --utc --date="$$d0 + 2 month + 1 day      " +%s`; \
MK>    j1=`expr 2440587 + $$d1 / 86400`; \
MK>    j2=`expr 2440587 + $$d2 / 86400`; \
MK>    echo -n "$$j1 $$j2" >expiry; \

 I agree with the removal of the second assignment to d1 but I don't think
adding "+1 day" to d1 and d2 is the right thing to do, even though it does
the same thing, of course, as this patch would do:

diff --git a/workhorse.make b/workhorse.make
index 44fcb70..70361ac 100644
--- a/workhorse.make
+++ b/workhorse.make
@@ -974,11 +974,10 @@ fardel_dir  := $(prefix)/$(fardel_name)

 fardel_date_script := \
   d0=`$(DATE) +%Y-%m-01`; \
-  d1=`$(DATE) --utc --date="$$d0 + 1 month         " +%s`; \
-  d1=`$(DATE) --utc +%s`; \
-  d2=`$(DATE) --utc --date="$$d0 + 2 months - 1 day" +%s`; \
-  j1=`expr 2440587 + $$d1 / 86400`; \
-  j2=`expr 2440587 + $$d2 / 86400`; \
+  d1=`$(DATE) --utc --date="$$d0 + 1 month " +%s`; \
+  d2=`$(DATE) --utc --date="$$d0 + 2 months" +%s`; \
+  j1=`expr 2440588 + $$d1 / 86400`; \
+  j2=`expr 2440588 + $$d2 / 86400`; \
   echo -n "$$j1 $$j2" >expiry; \

 # Several shared libraries are required by lmi, but there seems to be

But IMO fixing the JDN offset is more clear, I remember wondering why was
it apparently off by 1 the first time I saw it.

 Regards,
VZ