I'm afraid I am not going to do multiple timezones. Understand that we
don't even change the name of the timezone here when the offset changes.
And I am not going to touch the leap seconds either.
Yes, if you set your alarm for 7am 20 years ahead, it may well be that
powers have ruled and changed
On 4/8/2016 2:26 PM, I wrote:
> It would be nice to accept offsets in all formats valid to DEFINE
> TIMEZONE or ISO 8601, with or without a blank before the time zone or
> offset. East, West, and Z could conflict with valid CP time zones, though.
Wait, no, allowing blanks would get way too messy,
On 4/8/2016 5:31 AM, Rob van der Heij 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.
For an interval, I would certainly expect it to wait for the specified
duration, irrespective of
On 2016-04-08, at 10:39, John P. Hartmann wrote:
> For the sake of argument, suppose you set the wake up time for the bear
> to whatever it should be at the current time, say 9:00 on March 9 next
> year and congress then subsequently decides in view of various
> emergencies to extend summer time t
For the sake of argument, suppose you set the wake up time for the bear
to whatever it should be at the current time, say 9:00 on March 9 next
year and congress then subsequently decides in view of various
emergencies to extend summer time through winter (was it 1984?).
On 04/08/2016 06:10 PM, Da
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
On 2016-04-08, at 09:29, 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
On 2016-04-08, at 03:31, Rob van der Heij wrote:
>
> 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.
>
I agree.
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 to
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 bo
10 matches
Mail list logo
