Yes, a +72000 means wait for 2 hours, regardless of what time zone
you’re in or if the time zone changes while the wait is underway. That's
easy to understand and easy to document.
I also like the idea of including a item zone expression to the
time-of-day the DELAY stage is to wait; it's not am interval, it's a
specific date and time DELAY is to end. I think a "specific time"
includes the current time zone value. You want something to happen at
6:00 PM every day when EST is in effect, but at 5:00 PM in EDT. Of
course, I have not given any thought at all as to how difficult this
would be to implement.
Have a good one, too.
DJ
On 04/08/2016 10:29 AM, Hobart Spitz wrote:
I think that if you clearly document the distinction, then I would think
that different behaviors for +hh:mm versus hh:mm would make sense.
An alternative/additional solution, possibly too much trouble, would be to
add a timezone to the time specification: E.g. 10:30-EST, 18:15-CDT,
etc. Why too much trouble? No all countries change clocks on the same day.
I'm not sure how often this comes up, or why, so that might have a
bearing. If it's more than just clock changes in fall and spring, that
would matter.
Good luck.
On Fri, Apr 8, 2016 at 5:31 AM, Rob van der Heij <robvdh...@vnet.ibm.com>
wrote:
I did not want to bother the rest of the IBMVM list with this, but I could
use some votes on what we expect DELAY to do after a SET TIMEZONE was
issued.
No promises, but any comments on this?
I understand we want future delays started after the SET TIMEZONE to be
done
with the new timezone. The book says 'the specified time is reached' so it
seems appropriate to correct the working.
But what about the pop that is pending. I am tempted to distinguish
between an
interval (with a "+") and a time of day. So +7200 waits for 2 hours,
whether
clocks changed or not. But I know some plumbers compute it either way.
Sir Rob the Plumber
z/VM Development - CMS Pipelines
--
OREXXMan
--
Dave Jones
V/Soft Software
www.vsoft-software.com
Houston, TX
281.578.7544
