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

[Greg Chicares]

On 2010-05-31 12:14Z, Vadim Zeitlin wrote:
> On Sat, 22 May 2010 17:51:33 +0000 Greg Chicares <address@hidden> wrote:
[...]
> GC> On 2010-03-19 19:17Z, Greg Chicares wrote:
> GC> |
> GC> | $date
> GC> | Fri Mar 19 19:17:37 GMTST 2010
> GC> | $d0=`date +%Y-%m-01`
> GC> | $date --utc --date="$d0 + 1 month         "
> GC> | Thu Apr  1 00:00:00 UTC 2010
> GC> | $date --utc --date="$d0 + 2 months - 1 day"
> GC> | Fri Apr 30 00:00:00 UTC 2010

That example was misleading. A release that's valid through the thirtieth
of April must be usable throughout the last day of the month, but this:
> GC> | Fri Apr 30 00:00:00 UTC 2010
means the first moment of that day. Successive releases are valid for
contiguous intervals; there must be no "dead" day between them. Thus,
this was misleading, too:

On 2010-03-22 20:26Z, Greg Chicares wrote:
| 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.

If the end-date is April thirtieth, then this:
|     if(end <= candidate)
|       reject
would cause rejection at all times during the last day of the month.

Another easy way to see that these endpoints are wrong:
> GC> | Thu Apr  1 00:00:00 UTC 2010
> GC> | Fri Apr 30 00:00:00 UTC 2010
is to count the number of days between the beginning and the end. There
are only twenty-nine, whereas we want thirty days.

But wait. Looking back here:
  http://lists.nongnu.org/archive/html/lmi/2010-05/msg00020.html
to the June release's expiry date:
  2455377 was calculated, but we determined that
  2455379 would be correct.
That's off by two, not one. Updating the example, with your patch:

$date
Tue Jun  1 17:01:05 GMTST 2010
$d0=`date +%Y-%m-01`
$date --utc --date="$d0 + 1 month "
Thu Jul  1 00:00:00 UTC 2010
$date --utc --date="$d0 + 2 months"
Sun Aug  1 00:00:00 UTC 2010

shows that we've already got the right date, so why isn't that enough?
It turns out that the example was doubly misleading. It contained an
error, and it masked another. The "Sun Aug  1" result it displays is
obviously correct, but what actually gets written to 'expiry' depends
on the variables with 'j', not 'd':

$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

$echo "$j1 $j2"
2455379 2455410

Without the 's/2440587/2440588/' correction, "Sun Aug  1" got translated
to the day before, and that put both dates off by one. The end-date was
off by two because there were two off-by-one errors.

> GC> Now let's step back and ask whether we've handled timezone correctly.
> GC> I live in UTC, so a mistake here could easily escape my notice. With
> GC> your patch applied, we would have:
> GC> 
> GC> fardel_date_script := \
> GC>   d0=`$(DATE) +%Y-%m-01`; \
> GC>   d1=`$(DATE) --utc --date="$$d0 + 1 month " +%s`; \
> GC>   d2=`$(DATE) --utc --date="$$d0 + 2 months" +%s`; \
> GC>   j1=`expr 2440588 + $$d1 / 86400`; \
> GC>   j2=`expr 2440588 + $$d2 / 86400`; \
> GC>   echo -n "$$j1 $$j2" >expiry; \
> GC> 
> GC> It looks like 'd0' is local time,
> 
>  I think this is correct because, if I understand correctly, we want to use
> the "next month" in the current time zone. For example, right now it's
> already 2010-06-01 in New Zealand and if we used "--utc" in d0 definition,
> we'd compute expiry dates corresponding to July 2010 and not June as
> expected.

Yes, exactly.

> GC> but 'd1' and 'd2' have '--utc' in their formulas; we need to understand
> GC> whether '--utc' is helpful or harmful here, and why.
> 
>  It is helpful (even necessary) because the base offset 2440588 is for UTC.
> Without using UTC for d1 and d2 we wouldn't even get an entire number of
> days since 1970-01-01 UTC while we implicitly assume here that both d1 and
> d2 are congruent to 0 modulo 86400. We need to use the same time zone for
> both the base/epoch and the offset and using UTC for both ensures this.
> 
>  To see it in another way, the results of this computation shouldn't depend
> on the time zone it is done in except for the choice of the "next month"
> which is affected by it (on the first/last day of the month only but

That's important. If there's a mistake, we're likely to correct it on the
first day of the month. And we have done that at seven or eight pm local
time, when (depending on the season) the UTC date changes.

> still). This is precisely because we work with dates only, there is simply
> no way for the time zone effect (which is a fractional part of a day) to
> appear in the result. And to achieve this time zone independence we must
> use --utc as otherwise the results of `date +%s` are time zone dependent.

Here's what '%s' means according to the 'date' manual page:
  %s  seconds since 1970-01-01 00:00:00 UTC
so
  d1=`$(DATE) --utc --date="$$d0 + 1 month " +%s`
is the number of seconds between two measurements that are both relative
to UTC; the timezone therefore cancels. And this:
  d0=`$(DATE) +%Y-%m-01`
(notably with no '--utc') chooses the month based on what day it is in
the local timezone. And that's reliably correct as long as this command:
  date
displays the correct local time and zone. AFAICT, Cygwin uses the msw
timezone
  http://www.cygwin.com/ml/cygwin/2003-05/msg00555.html
| Cygwin time *is* Windows time.
unless $TZ is explicitly overridden (as it generally should not be).

I've committed your patch, and also changed a diagnostic. This:
  Current date '2010-07-01' is invalid: this system expired on '2010-07-01'.
is potentially confusing because it doesn't say what time the system
expires; OTOH, this:
  Current date 2010-07-01 is invalid: this system cannot be used after 
2010-06-30.
clearly suggests that expiry occurs when the date changes.