On Oct 7, 2011, at 17:09, Rob van der Heij wrote:
> On Sat, Oct 8, 2011 at 12:42 AM, Paul Gilmartin <[email protected]> wrote:
>
>> First day of the month. But that shouldn't matter.
>
> And you're 7 hrs from GMT maybe? If I had written it myself, I would
> think that I did something silly when computing the next day. But CMS
> Pipelines normally does not have that kind of problems.
>
Actually, from the headers of the message it generated:
Date: Mon, 26 Sep 2011 07:00:00 -0600
(The offset was returned by DIAG) It's -6, not +7. So it
was at 13:00 GMT, well away froom the hazard you might suspect.
But you started me thinking about a possible implementation:
1) DIAG to get the offset.
2) STCK to get the GMT.
3) Add offset to GMT to get local time.
4) take Floor of local time modulo 24 hours to get
prior midnight.
5) Add Delay argument
6) subtract offset to get back to GMT.
7) load Clock Comparator.
Steps (5) and (6) can be swapped (as can (1) and (2)) with
no effect on the result. The trickiest step is (4), and even
that's unlikely to result in "PIPDEL400E Delay 31:00 is not
acceptable."
But there is one flaw in that scheme. Since the time of my
daily event is arbitrary, I believe I'll try changing to:
"... 24:30 | delay ..." and watch to see what happens on
November 6, when Daylight Saving Time ends and at 02:00
local time is set back to 01:00.
Any predictions?
(I suspect the behavior of LITERAL 47:59:59.999 |
DUPLICATE * | DELAY is apt to be erratic.)
-- gil
