Stan Ryckman responded to a post from me,
| Well, if I remember your previous posts on the subject, you don't
| want to run the "date" program or any other. Not sure why; if it
| happens a lot, the thing should be cached anyway. But since you seem
| willing below to cave in and run it *sometimes*... for a week at a
| time...
For a week at a time only twice a year, and even at that I wasn't too happy
with it. I got it down to two hours a year.
I don't know how often it happens or how much I can rely on its being cached.
All I know is that most of the dang info is there already anyway. I did
finish the rcfile; now it needs to run date only for two hours a year
(from 1 AM daylight time to 2 AM standard time on the reversion date), and
that means not at all, because this routine is invoked only interactively,
not by incoming mail, and I'm asleep when the clocks change back.
And the only formatting character I need is +%Z, which is a lot easier to
keep correct than the format string needed to generate a complete header.
| > In the US we set clocks ahead on the first Sunday in April and back on
| > the last Sunday in October ...
| (Unless you're in parts of Indiana or a few other places. And in other
| parts of the world, the dates are different as well. So if you want
| to be general, read on as well.)
If I move this to a system in another city, I'll adjust the routines then. I
don't expect to relocate frequently if ever. If I move it to another ISP in
Chicago or to another ISP in this time zone, I don't need to change a thing.
| > I could further ... reduc[e] the need to run date from fourteen
| > days a year to two hours a year ...
| Or you can do that stuff before the following as well. But why the
| bother, really? You can use your above to decide whether to do the
| following (which involve running date) or not, but I think it's wrong.
| People time (i.e., yours) is more costly and valuable than a huge
| number of executions of the date program, and you could still end up
| with bugs.
But my people time is already put in and done; it didn't take long. Now it
is good for as long as I run it in my home town. It requires major changes
only if I relocate to a place where the time change dates are different, and
minor changes if I relocate to a different time zone in the US. If I move
to Arizona, Hawaii, or the eighty-one counties in Indiana that stay on EST
all year, I don't need to change it at all, just set the zone statically
and keep the file around in case I move again.
| I see two choices. The simplest is just construct your
| Resent-Date: header from `date -u` (with appropriate format) and send
| it out as GMT (or in the now-preferred "+0000" form). Actually, I'd
| recommend this because it should *ALWAYS* work, even if they change
| the first Sunday in April to the third Sunday in February next year
| (or something). Well worth the extra times you'll run the
| date program, given the mental anguish you'll save.
Mental anguish? No, really, it was fairly easy to write, so it shouldn't
be that hard to modify. I did consider always using UTC for it, because then
I could hard-code the zone as UTC and the offset as +0000, but that violates
your own principle of making computers work instead of people: I'd always
have to convert it back to current C[SD]T for it to be meaningful to me when
I look at the output.
| Plus the fact you'll surely forget to change your script when Congress
| changes the law or when you send a computer off to Indiana (or when you
| start running on a computer that uses native GMT, period).
Big BZZZZT on the last one, Stan. Some things I wouldn't forget. And you
don't even allow that I *might* remember; you're POSITIVE I'll forget!
| The second choice is to get the hour from both `date` and `date -u`,
| do a little arithmetic, and you'll have the time zone. Tiny little
| race condition at the two critical moments of the year, though.
| To be portable, you'll have to worry about half-hour time zones in
| a few places though :-)
The time zone acronym is provided by date +%Z, which procmail can look at
to pick the numeric time zone offset:
SUMMERZONE=CDT WINTERZONE=CST SUMMEROFFSET=-0500 WINTEROFFSET=-0600
ZONE=`date +%Z`
:0
* $ ZONE ?? $SUMMERZONE
{ OFFSET=$SUMMEROFFSET }
:0E
* $ ZONE ?? $WINTERZONE
{ OFFSET=$WINTEROFFSET }
[Since the offset is appended to a time figured a few ticks earlier, yes,
it is also subject to a race condition twice a year, but I'm asleep at those
two moments.] That is one fork to run date +%Z and I need only redefine the
variables if I move to another zone, whereas your subtraction suggestion
requires this (and it still doesn't deal with half-hour time zones):
HOURHERE=`date +%H`
UTCHOUR=`date -u +%H`
OFFSET=`expr $HOURHERE - $UTCHOUR`
:0 # and test might invoke a shell ...
* ? test $OFFSET -gt 12
OFFSET=| expr $OFFSET - 24
:0
* OFFSET ?? -\/.^^
{ OFFSET=-0${MATCH}00 }
:0E
* OFFSET ?? -..
{ OFFSET=${OFFSET}00 }
:0E
* OFFSET ?? ^^.^^
{ OFFSET = +0${OFFSET}00 }
:0E
* OFFSET ?? ^^[^-].
{ OFFSET=+${OFFSET}00 }
Do it if you want, Stan, but it's not the way I'd go.