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

[Greg Chicares]

On 2010-05-14 18:10Z, Vadim Zeitlin wrote:
> On Thu, 13 May 2010 15:07:18 -0400 "Murphy, Kimberly" <address@hidden> wrote:
[On 2010-03-22 20:26Z, Greg Chicares wrote:]
> > > 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).

For example, if we package a distribution in the same timezone as
New York, and ship it to New Zealand, then it should expire at
exactly midnight according to the user's clock, which is probably
set to either NZST or NZDT. For June, it's valid between these
moments, inclusive:
  2010-06-01T00:00:00.000
  2010-06-30T23:59:59.999
and the date part (before the 'T') is the same everywhere, but the
time part is civil time wherever the user is located.

Thus, in 'expiry', we want the date, but not the time. Accordingly,
the script returns integers:

> MK> 2455329 2455377

because Julian Day Number (see below) is an integer.

> MK> which coverts to:
> MK> 
> MK> JD 2455329.00000 is
> MK> CE 2010 May 12 12:00:00.0 UT  Wednesday

"JD" above means "Julian Date", which is a floating-point number that
represents both date and time. "UT" means "Universal Time", which is
more or less the time in England without regard to British Summer Time.
A fractional part equal to zero means noon because the astronomical
convention is followed: traditionally, English astronomers worked at
night, and midnight came in the middle of their "workday", so they
found it convenient their date to change at noon.

What we want differs in three respects:
 - we want an integer, not a floating-point number (day, no time)
 - we follow local time, not Universal Time
 - our dates change at midnight, not noon.
IOW, we want "Chronological Julian Day Number":
  http://www.hermetic.ch/cal_stud/jdn.htm#chronological

> MK> 2455317.5 2455347.5
> MK> 
> MK> generates this error when launching Lmi:
[...]
> 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.

"What day is this?" is the only question that matters.
"What time of day is it?" does not matter.

Therefore, the code deliberately rejects floating-point input.
Only a JDN is wanted, so only an integer is accepted.

> 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.

That might very well be exactly what we should do. We must be cautious,
however, because this feels uncomfortably like a trap that's all too
easy to fall into. Off-by-one errors are difficult to remove because
they seem so easy: we have a failing testcase, intuition tells us that
adding or subtracting one "somewhere" should suffice, and there's a
strong temptation to forge ahead with any adjustment that appears to
cure the observed failure. Yet demonstrable absence of the symptom for
a single testcase does not prove that the underlying problem has been
eradicated or that no others exist.

The 's/2440587/2440588/' part is good, because it answers the code-
inspection question
  "why does this constant have an apparently incorrect value?"
rather than the "just-fix-it" question
  "where shall we add or subtract one?"
as you explain:

>  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.

And this isn't controversial:
>  I agree with the removal of the second assignment to d1
because the code contains a comment that explains it: we wouldn't use
the second assignment unless we want to override the usual beginning
date with the current date.

As for this part of the patch:

> -  d2=`$(DATE) --utc --date="$$d0 + 2 months - 1 day" +%s`; \
> +  d2=`$(DATE) --utc --date="$$d0 + 2 months" +%s`; \

can we say where the following example (with '- 1 day') was misleading?

On 2010-03-19 19:17Z, Greg Chicares wrote:
|
| $date
| Fri Mar 19 19:17:37 GMTST 2010
| $d0=`date +%Y-%m-01`
| $date --utc --date="$d0 + 1 month         "
| Thu Apr  1 00:00:00 UTC 2010
| $date --utc --date="$d0 + 2 months - 1 day"
| Fri Apr 30 00:00:00 UTC 2010

Now let's step back and ask whether we've handled timezone correctly.
I live in UTC, so a mistake here could easily escape my notice. With
your patch applied, we would have:

fardel_date_script := \
  d0=`$(DATE) +%Y-%m-01`; \
  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; \

It looks like 'd0' is local time, but 'd1' and 'd2' have '--utc'
in their formulas; we need to understand whether '--utc' is helpful
or harmful here, and why. (I suspect it's correct because of what
'%s' means, but it seems best to ask for another opinion because,
for me, timezone vanishes.)