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

[Vadim Zeitlin]

On Sat, 22 May 2010 17:51:33 +0000 Greg Chicares <address@hidden> wrote:

GC> For example, if we package a distribution in the same timezone as
GC> New York, and ship it to New Zealand, then it should expire at
GC> exactly midnight according to the user's clock

 Thanks for making this clear, I was not 100% sure about this.

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

 Not to beat a dead horse but if this is the precise definition that we use
then we definitely must use 2440588 as the CJDN of the Unix Epoch, my
doubts were only due to the fact that I wasn't sure if there wasn't some
other convention (there are so many of them...) that was off by 1 compared
to this, usual one.

 This can be confirmed by checking that the link above says that
CJDN(2003-11-08) is 2452952 and by dividing the result of `date -d
2003-11-08 -u +%s` by 86400 you can see that 12364 days separate this date
from the Epoch, hence CJDN(1970-01-01)=2452952-12364=2440588.

GC> The 's/2440587/2440588/' part is good
...
GC> And this isn't controversial:
GC> >  I agree with the removal of the second assignment to d1

 So let's consider the above two points agreed on.


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

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

 Regards,
VZ