BST to GMT

[Ian McKerracher]

This submission may be of interest to UK members.

I have just been checking the date (SYS$TIMEZONE_RULE) for the end of British Summer Time on each of our two Alpha DS10s (both OpenVMS V7.3-2). One date is 31/10/2004 (which is correct) and the other date is 24/10/2004 (which is incorrect). My investigation revealed that the system with the correct date is running DECnet-Plus V7.3-2 but the system with the incorrect date is running DECnet-Plus V7.3-1.

DECnet-Plus V7.3-1 was released in May 2002 (?) which was around the time that the UK government adopted the European convention of changing on the last Sunday in October instead of the Sunday following the fourth Saturday.

I would advise our UK members to check SYS$TIMEZONE_RULE in the next week or two before the time changes a week early.

Regards,

Ian

[Ian Miller.]

Well spotted !
$ mcr ncl show dtss next tdf change
on a system DECnet-Plus for OpenVMS Version V7.1-ECO06 shows the incorrect date.

But on a system running DECnet/OSI V7.3-1 ECO02 system its fine.

I'd better go and check somemore

[John Gillings]

Ian(s),

Unfortunately, most of this code is written by Americans, for Americans. In the USA, time zone rules are practically written into the constitution! So, the usual answer to any questions regarding rule changes is "Huh? Why?".

Engineering aren't in the business of tracking arbitrary rule changes across the planet, so will refer you to the tools for changing rules. Some CSCs keep track of changes and publish corrections for their local area. For example, you can find up to date rules for Australia and New Zealand at http://ftp.hp.com.au . Contact your local CSC to see if they do something similar (or request that they do).

Note that in versions prior to V7.3 had separate rules for DTSS and TCPIP.

In Australia, time zone rules have been know to change with as little as 3 weeks notice, so the idea of automated changes is not necessarily a good one. Instead of just adjusting clocks twice a year, we have to adjust the adjustement tables twice a year.

[Ian Miller.]

Using @SYS$STARTUP:NET$CONFIGURE ADVANCED then option 5 then option 3 type in own rule I can get the correct result shown for
$ mcr ncl show dtss next tdf change

If I enter GMT0BST1,M4.1.0/2,M10.5.0/2 as the rule.

I have also entered this in UCX.

I have had some fun with the system TDF being set to -1 instead of +1 when I did this :-) Luckly I was doing this on a test system. I corrected the TDF with @SYS$STARTUP:UTC$CONFIGURE_TDF then option 1 then enter 1 for the TDF and move the time forward 2 hours.

Has anyone seen this (TDF being set wrong)?
DECnet-Plus for OpenVMS Version V7.1-ECO05

[Ian Miller.]

Noone spotted the mistake :-) The rule should be GMT0BST-1,M3.5.0/1,M10.5.0/1

Although looking at that I wonder if the last /1 should be /2

It appears that the correct rule is in Sys$update:dtss$timezone_rules.dat so why was it wrong?

[Ian McKerracher]

Ian,

I believe that M10.5.0/1 should be M10.5.0/2 as the trailing "/2" indicates that the time changes at 2:00AM i.e. 02:00 BST becomes 01:00 GMT.


Regards,

Ian

[Ian Miller.]

yes that's what I thought. I will change it to /2 try again (I'm still only doing this on test system).