Daylight Savings change - 'tis the time of year to think about it
P. Sture
it right, I don't know how to check it on V8.3.
Way back when, before SYSGEN parameter AUTO_DLIGHT_SAV was introduced
(V7.3?), and running DTSS; the command was:
$ mcr ncl show dtss next tdf change
Since AUTO_DLIGHT_SAV was introduced, I have been running with DTSS
disabled, so hat command doesn't work any more.
Suggestions for checking when the date will change on V8.3 please!
--
Paul Sture
Sue's OpenVMS bookmarks:
http://eisner.encompasserve.org/~sture/ovms-bookmarks.html
Peter Weaver
P. Sture wrote:
>...
> Suggestions for checking when the date will change on V8.3 please!
I do not know what the official way is but I hacked this together one
day when I was trying to figure out whay SYS$DST_DELTA_TIME was off by
some number of seconds (on the system I just ran this on it is about
58 seconds off). Does anyone else know why SYS$DST_DELTA_TIME is not
quite right?
$ type check_next_dst.com
$!
$ if "''f$trnlnm("SYS$DST_DELTA_TIME")'" .nes. "" then goto
HAVE_DTS_DELTA_TIME
$!
$ write sys$output "No SYS$DST_DELTA_TIME defined, nothing to do."
$!
$ goto end
$!
$HAVE_DTS_DELTA_TIME:
$!
$ binary_time[0,32] = %X'f$extract(8,8,f$trnlnm("SYS
$DST_DELTA_TIME"))
$ binary_time[32,32] = %X'f$extract(0,8,f$trnlnm("SYS
$DST_DELTA_TIME"))
$!
$ date_string= -
f$edit(f$fao("!%D",f$cvui(32,32,f$fao("!AD",
8,binary_time))),"TRIM")
$!
$ if f$locate(" ",date_string) .eq. f$length(date_string)
$ then
$ date_string2 = datestring
$ else
$ date_string2 = -
"''f$element(0," ",date_string)'-''f$element(1,"
",date_string)'"
$ endif
$!
$ next_dst = f$cvtime("''f
$getsyi("boottime")'+''date_string2'","ABSOLUTE")
$!
$ write sys$output -
"The next DST change will be a few seconds after ''next_dst'"
$!
$!
$end:
$ @check_next_dst
The next DST change will be a few seconds after 4-NOV-2007 01:59:02.95
Peter 'EPLAN' LANGSTOeGER
>Someone reminded me of this today, and while I'm sure that VMS will get
>it right, I don't know how to check it on V8.3.
>
>Way back when, before SYSGEN parameter AUTO_DLIGHT_SAV was introduced
>(V7.3?), and running DTSS; the command was:
>
>$ mcr ncl show dtss next tdf change
>
>Since AUTO_DLIGHT_SAV was introduced, I have been running with DTSS
>disabled, so hat command doesn't work any more.
>
>Suggestions for checking when the date will change on V8.3 please!
It is still the SYS$TIMEZONE_RULE logical (posix timezone rules/names)
"CET-1CEST-2,M3.4.0/02,M10.4.0/03"
means CEST will change back at the 4th (.4.) Sunday (0) in October (M10)
at 3:00 in the morning (/03) back to 02:00 CET
--
Peter "EPLAN" LANGSTOEGER
Network and OpenVMS system specialist
E-mail pe...@langstoeger.at
A-1030 VIENNA AUSTRIA I'm not a pessimist, I'm a realist
P. Sture
pe...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote:
> In article <paul.sture.nospam-4...@mac.sture.ch>, "P. Sture"
> <paul.stu...@hispeed.ch> writes:
> >Someone reminded me of this today, and while I'm sure that VMS will get
> >it right, I don't know how to check it on V8.3.
> >
> >Way back when, before SYSGEN parameter AUTO_DLIGHT_SAV was introduced
> >(V7.3?), and running DTSS; the command was:
> >
> >$ mcr ncl show dtss next tdf change
> >
> >Since AUTO_DLIGHT_SAV was introduced, I have been running with DTSS
> >disabled, so hat command doesn't work any more.
> >
> >Suggestions for checking when the date will change on V8.3 please!
>
> It is still the SYS$TIMEZONE_RULE logical (posix timezone rules/names)
>
> "CET-1CEST-2,M3.4.0/02,M10.4.0/03"
>
> means CEST will change back at the 4th (.4.) Sunday (0) in October (M10)
> at 3:00 in the morning (/03) back to 02:00 CET
Thanks, but that means I've got to look the date up in a calendar :-)
Another solution, supplied offline:
$ @SYS$MANAGER:UTC$TIME_SETUP SHOW
AUTO_DLIGHT_SAV is set to "1".
OpenVMS will automatically change to/from Daylight Saving Time.
(in time zones that use Daylight Saving Time)
LOCAL TIME ZONE = EUROPE / ZURICH -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 20-SEP-2007 13:12:52.03 (CEST)
TIME DIFFERENTIAL FACTOR = 2:00
TIME ZONE RULE = CET-1CEST-2,M3.4.0/02,M10.4.0/03
Change CET to CEST on the Fourth Sunday of March (25-Mar-2007) at 02:00
Change CEST to CET on the Fourth Sunday of October (28-Oct-2007) at 03:00
Peter 'EPLAN' LANGSTOeGER
>Another solution, supplied offline:
>
>$ @SYS$MANAGER:UTC$TIME_SETUP SHOW
Try it on a VAX ;-)
%UTC-F-NOSUCHDIR, directory SHOW[SYSEXE] not found
%UTC-I-CHECKP1, check target root parameter P1
P. Sture
pe...@langstoeger.at (Peter 'EPLAN' LANGSTOeGER) wrote:
> In article <paul.sture.nospam-4...@mac.sture.ch>, "P. Sture"
> <paul.stu...@hispeed.ch> writes:
> >Another solution, supplied offline:
> >
> >$ @SYS$MANAGER:UTC$TIME_SETUP SHOW
>
> Try it on a VAX ;-)
>
> %UTC-F-NOSUCHDIR, directory SHOW[SYSEXE] not found
> %UTC-I-CHECKP1, check target root parameter P1
well I did specify V8.3 in my original question :-)
Neil Rieck
> In article <46f226a...@news.langstoeger.at>,
[...snip...]
>
> $ @SYS$MANAGER:UTC$TIME_SETUP SHOW
>
> AUTO_DLIGHT_SAV is set to "1".
> OpenVMS will automatically change to/from Daylight Saving Time.
> (in time zones that use Daylight Saving Time)
>
> LOCAL TIME ZONE = EUROPE / ZURICH -- DAYLIGHT TIME
> LOCAL SYSTEM TIME = 20-SEP-2007 13:12:52.03 (CEST)
> TIME DIFFERENTIAL FACTOR = 2:00
> TIME ZONE RULE = CET-1CEST-2,M3.4.0/02,M10.4.0/03
> Change CET to CEST on the Fourth Sunday of March (25-Mar-2007) at 02:00
> Change CEST to CET on the Fourth Sunday of October (28-Oct-2007) at 03:00
>
I'm not sure if Europe adopted changes proposed by the Bush
Administration but I know the dates shown above are different from
most places in North America. Here is the output from OpenVMS-8.2 in
Ontario, Canada. Notice the string "M11.1" which means first weekend
of November.
###
KAWC15::Neil> $ @SYS$MANAGER:UTC$TIME_SETUP SHOW
AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use.
You will have to manually change to/from Daylight Saving Time.
You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,
or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.
LOCAL TIME ZONE = CANADA / EASTERN -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 22-SEP-2007 08:23:49.83 (EDT)
TIME DIFFERENTIAL FACTOR = -4:00
TIME ZONE RULE = EST5EDT4,M3.2.0/02,M11.1.0/02
Change EST to EDT on the Second Sunday of March (11-Mar-2007) at
02:00
Change EDT to EST on the First Sunday of November (4-Nov-2007) at
02:00
KAWC15::Neil>
###
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.
http://www3.sympatico.ca/n.rieck/
Neil Rieck
> On Sep 20, 7:15 am, "P. Sture" <paul.sture.nos...@hispeed.ch> wrote:
>
[...snip...]
>
> I'm not sure if Europe adopted changes proposed by the Bush
> Administration but...
>
Please disregard the above comment. Obviously my caffeine meter was on
"E"
:-)
Neil Rieck
Kitchener/Waterloo/Cambridge,
Ontario, Canada.http://www3.sympatico.ca/n.rieck/
Jim
Cool. I'd suggest one small change. I beleive that the delta is
actually the separation from when the JOB_CONTROL process scheduled
the event (which will be shortly after boot unless the JOB_CONTROL
process has been stopped and restarted). So, how about the following
which should result in a return value very close to what is expected.
$! check_next_dst.com - Peter Weaver
$ ctx = ""
$ p1 = f$context("process",ctx,"nodename",f$getsyi("nodename"),"eql")
$ p1 = f$context("process",ctx,"username","SYSTEM","eql")
$ p1 = f$context("process",ctx,"prcnam","JOB_CONTROL","eql")
$ pid = f$pid(ctx)
$ jobctl_start = f$getjpi(pid,"logintim")
$ next_dst = f$cvtime("''jobctl_start'+''date_string2'","ABSOLUTE")
$!
$ write sys$output -
"The next DST change will be a few seconds after ''next_dst'"
$!
$!
$end:
$ exit
Volker Halle
as discussed in de.comp.os.vms this weekend (most of Europe changed to
Standard Time last weekend), you cannot rely on the value in SYS
$DST_DELTA_TIME or SYS$TIMEZONE_RULE if your system time is NOT in the
same year as the next daylight saving time change event.
With AUTO_DLIGHT_SAV=1, you can easily use SDA to find out about the
next event:
$ ANAL/SYS
SDA> SHOW PROC/TQE JOB_CONTROL
SDA> EXIT
There will be a TQE scheduled for the next TDF change event. On the
more recent versions of OpenVMS (like I64 V8.3), you may see the TQE
scheduled for 1-JAN-2008 - the updated values for SYS$DST_DELTA_TIME
or SYS$TIMEZONE_RULE will be set correctly for 2008 at that time.
Volker.
Volker Halle
as run from within SYS$MANAGER:JBC$DST_COMMAND.COM executed by
JOB_CONTROL, when the time change TQE is due. JOB_CONTROL uses the
value of this logical to just set up the TQE for the next time change
TQE.
So in general - except after a boot after a time change event, you
cannot use the value of SYS$DST_DELTA_TIME to exactly predict the next
event, as you can't find out, when JBC$DST_COMMAND.COM was last run by
JOB_CONTROL.
The SDA> SHOW PROC/TQE JOB_CONTROL is the most reliable way to
determine the time for the next time change event (if using
AUTO_DLIGHT_SAV=1).
If the TQE points to 1-JAN-next_year, then you'll have to wait until
that date and the contents of the then-current SYS$TIMEZONE_RULE,
which will allow SYS$DAYLIGHT_SAVING.EXE to calculate the time of the
next daylight time change event.
Volker.
jhjr4381
>
> - Show quoted text -
Wierd, anybody know why I'm getting this? Is there a patch I'm
missing?
$ @sys$manager:utc$time_setup show
AUTO_DLIGHT_SAV is set to "0" and DTSS is not in use.
You will have to manually change to/from Daylight Saving Time.
You can do this by executing SYS$MANAGER:UTC$TIME_SETUP.COM,
or you can use SYS$EXAMPLES:DAYLIGHT_SAVING.COM.
LOCAL TIME ZONE = US / EASTERN -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 2-NOV-2007 07:34:10.20 (EDT)
TIME DIFFERENTIAL FACTOR = -5:00
TIME ZONE RULE = EST5EDT4,M4.1.0/02,M10.5.0/02
Change EST to EDT on the First Sunday of April (1-Apr-2007) at
02:00
%DCL-W-IVATIME, invalid absolute time - use DD-MMM-YYYY:HH:MM:SS.CC
format
\32-OCT\
%DCL-E-INVIFNEST, invalid IF-THEN-ELSE nesting structure or data
inconsistency
I did:
set time=02-NOV-2007:07:34:02.0
and I still get the same results. \32-OCT\ ?- Looks like something
Sales & Accounting would love for bookings! Does this mean absolute
time adjustment is pushing the date to Oct 32nd?
Regards,
Dan
Volker Halle
consider to add a SET VERIFY to your UTC$TIME_SETUP.COM a couple of
lines after the $day_to1: label:
...
$! Get the from-daylight change info
$ SET VERIFY
$...
Then execute the procedure again. Please note that your Time Zone Rule
is probably incorrect for your the EST time. Shouldn't it be
M11.1.0/02 instead of M10.5.0/02 ? You are supposed to change to EST
on the first sunday in November 2007 at 02:00 am.
Volker.
jhjr4381
I re-ran the:
SYS$MANAGER:UTC$TIME_SETUP.COM, selected US/ Eastern time zone, and
now have:
LOCAL TIME ZONE = US / EASTERN -- STANDARD TIME
LOCAL SYSTEM TIME = 2-NOV-2007 10:04:33.14 (EST)
TIME DIFFERENTIAL FACTOR = -4:00
TIME ZONE RULE = EST5EDT4,M4.1.0/02,M10.4.0/02
Change EST to EDT on the First Sunday of April (1-Apr-2007) at
02:00
Change EDT to EST on the Fourth Sunday of October (28-Oct-2007) at
02:00
And you are correct, The EDT to EST should be M11.1.0/02 (02-Nov-2007)
not M10.4.0/02 (28-Oct-2007). So, how do I correct the actual time
zone rule EST5EDT4?
Thanks in advance.
Dan
jhjr4381
>
> - Show quoted text -
I ran the:
@sys$examples:daylight_savings.com and took the option to 'save' the
file (should this then execute on my next boot?). Then I went into the
tdf$utc_startup.com and at the bottom I have:
DTSS$SET_TIMEZONE := $SYS$SYSTEM:TDF$SET_TIMEZONE.EXE
$ DTSS$SET_TIMEZONE INITIALIZE
"EST5EDT4,M4.1.0/02,M10.4.0/02" (here's my 28-Oct-2007)!
If I modify this to:
DTSS$SET_TIMEZONE := $SYS$SYSTEM:TDF$SET_TIMEZONE.EXE
$ DTSS$SET_TIMEZONE INITIALIZE "EST5EDT4,M4.1.0/02,M11.1.0/02"
should that then solve the problem?
Sorry, I should have looked before asking my last question!
Volker Halle
seem to be missing some OpemVMS timezone related patch. There were a
couple of those patches released during last year due to the timezone
changes in the US.
Please have a look at:
http://h71000.www7.hp.com/dst.html?jumpid=reg_R1002_USEN
You need to submit the temporary procedure saved to
DAYLIGHT_SAVINGS.COM to actually run on the desired time to switch
back from EST to EDT. Depending on your OpenVMS version, you have VMS
do the change for you by setting AUTO_DLIGHT_SAV=1 (OpenVMS V7.3 or
higher, not on VAX).
Volker.
jhjr4381
So, if I understand you correctly then. If I set Auto_dlight_sav=1
(now = 0), it should execute automatically (or I can schedule the .com
file to execute.
However , since:
$ show log SYS$TIMEZONE_RULE
"SYS$TIMEZONE_RULE" = "EST5EDT4,M4.1.0/02,M10.4.0/02" (LNM
$SYSTEM_TABLE)
is incorrect, then it should be ok if I manually change that (to
M11.1.0/02" rule for now (then download the patch)? Since I don't have
time now to apply the patch at this point.
Thanks and regards,
Dan
Volker Halle
you need to manually submit the procedure created by
DAYLIGHT_SAVINGS.COM to run on 4-NOV-2007:02:00 to change the local
system time to EST. It is hard to predict what happens with the system
time, if your timezone rule is wrong.
Changing to AUTO_DLIGHT_SAV=1 requires a reboot. It also does not help
you, if the rule is still wrong due to the missing patch. Manually
editing TDF$UTC_STARTUP.COM does not help, as that file is only run
during boot.
Good luck,
Volker.