Questions regarding SYS$TIME_ZONE_DIFFERENTIAL

[Andreas Fassl]

Hello,
this is related to a migration from parts of an interface to a different machine.
I found a problem within the time stamps.
After the first analysis I'm think the reason are different values for SYS$TIME_ZONE_DIFFERENTIAL.
----------------------------
When I do a query on node A (an older vms system with VMS 6.1)
@sys$manager:utc$configure_tdf


Configuring the Time Differential Factor

Enter ? anytime for help

[0] Exit
[1] Set the Time Differential Factor
[2] Display the Time Differential Factor

* Please pick an option number [2]: 2

SYSTEM TIME DIFFERENTIAL FACTOR = -13:00 (-46800 seconds).
LOCAL SYSTEM TIME = 13-MAY-2006 22:47:55.71.
--------------------------------------------
Doing the same on node B:
@sys$manager:utc$configure_tdf


Configuring the Time Differential Factor (TDF)

Enter ? anytime for help

[0] Exit
[1] Set the Time Differential Factor
[2] Display the Time Differential Factor

Please pick an option number [2]: 2

SYSTEM TIME DIFFERENTIAL FACTOR = 2:00 (7200 seconds).
LOCAL SYSTEM TIME = 13-MAY-2006 22:43:11.65.

------------------------------------------------



Node B will get the software from Node A. The easiest solution is (IMHO) to reconfigure Node B. But I can't do this. After some research within the wizard area and the superb ITRC forums I tried to use the non obsolete way:

@sys$manager:utc$time_setup "" show
%UTC-I-UPDTIME, updating Time Zone information in SYS$COMMON:[SYSEXE]
Configure which time parameter (TIMEZONE/TDF/BOTH/NONE)? [BOTH]


Configuring the Local Time Zone


TIME ZONE SPECIFICATION -- Main Time Zone Menu

1) Australia 11) GMT 21) Mexico 31) Turkey
2) Brazil 12) Greenwich 22) NZ 32) UCT
3) CET 13) Hong Kong 23) NZ-CHAT 33) US
4) Canada 14) Iceland 24) Navajo 34) UTC
5) Chile 15) Iran 25) PRC 35) Universal
6) Cuba 16) Israel 26) Poland 36) W-SU
7) EET 17) Jamaica 27) ROC 37) WET
8) Egypt 18) Japan 28) ROK 38) Zulu
9) Factory 19) Libya 29) Singapore
10) GB-Eire 20) MET 30) SystemV

0) None of the above

Select the number above that best represents the desired time zone: 20

You selected MET as your time zone.
Is this correct? (Yes/No) [YES]:

Default Time Differential Factor for standard time is 1:00.
Default Time Differential Factor for daylight saving time is 2:00.


Configuring the Time Differential Factor (TDF)

Enter ? anytime for help

[0] Exit
[1] Set the Time Differential Factor
[2] Display the Time Differential Factor

Please pick an option number [2]: 1


The Time Differential Factor (TDF) is the difference between your
system time and Coordinated Universal Time (UTC). UTC is similar
in most repects to Greenwich Mean Time (GMT).

The TDF is expressed as hours and minutes, and should be entered
in the hh:mm format. TDFs for the Americas will be negative
(-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
will be positive (1:00, 2:00, etc.).

Is Daylight Savings time in effect? (Yes/No): -13:00
You must enter "YES" or "NO"!
Is Daylight Savings time in effect? (Yes/No): yes

Enter the Time Differential Factor [2:00]: -13:00

%UTC-E-ILLTDFVAL, -13:00 is not a legal TDF value
%UTC-I-TDFRANGE, response must be in the range -13:00 > TDF < 13:00

Type CTRL-Y to goto the first menu


The Time Differential Factor (TDF) is the difference between your
system time and Coordinated Universal Time (UTC). UTC is similar
in most repects to Greenwich Mean Time (GMT).

The TDF is expressed as hours and minutes, and should be entered
in the hh:mm format. TDFs for the Americas will be negative
(-3:00, -4:00, etc.); TDFs for Europe, Africa, Asia and Australia
will be positive (1:00, 2:00, etc.).

Is Daylight Savings time in effect? (Yes/No):



Is there a way to set the TDF to -13:00? Even though negative values are for america, but I hope, this is the easiest way to get rid of this last problem during the migration.

The source code isn't documented in this part and over 10 years old, so I would be very happy to get rid of this problem with an easier to handle system configuration.

Thanks in advance

Andreas

[Robert Gezelter]

Andreas,

This is untested, as I am in the middle of something (so I don't have a system that I can potentially disrupt at this instant).

A casual examination of STS$MANAGER:UTC$TIME_SETUP.COM appears to indicate that there is a discrepancy between the displayed text "-13:00 < TDF < 13:00". The actual test appears to be:

$ if (tdf_val .gt. max_tdf) .or. (tdf_val .le. min_tdf)

Thus, the bounds checking would appear to be off by 1 minute. A possible (unchecked) fix would be to change the ".le." to ".lt." in the above cited line.

This line was found on an Alpha 7.3-2 system. Checked casually (30 seconds of hand checking), I do not offhand see a problem with making this change. I would recommend testing it on a test environment before trying it on a production system.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[Andreas Fassl]

Dear Bob,

thanks, found this as an option, too. But is this a supported value anyway?
The usage of x < y with x.lt.y is correct (to be some sort of a smart one, :-)).
If noone has got another hint, I'll think I'll try this, you get heaps of points and I'll close the thread.

Thanks alot,

Andreas

[Robert Gezelter]

Andreas,

It is not a guarantee, but this has the look of one of the more garden variety of coding errors (e.g., aka "+/- 1 errors"). Since the documentation is pretty clear, and virtually all offsets from UTC (formerly known as GMT) aka Zulu, I would try it, albeit with appropriate precautions.

- Bob Gezelter, http://www.rlgsc.com

[Robert Gezelter]

Andreas,

Also, you can check a world map which includes time zone offsets. I would think that it is reasonable to presume that the testing was done for everything up to and including the International Date Line.

- Bob Gezelter, http://www.rlgsc.com

[John Gillings]

If UTC$CONFIGURE_TDF doesn't recognise the full range of time zone offsets [-13.75 : +13.0] inclusive, then it's a bug. Please report it against your service contract.

There was a similar TDF range check bug in SYSINIT.EXE, fixed in V7.2-2

[John Gillings]

Very odd!

I found a version of UTC$CONFIGURE_TDF.COM which has a documented fix dated 3-Dec-1999:
"New TDF verification: -25 =< TDF =< 25."

The modification was made in response to requests from New Zealand customers who needed an offset of 13 hours.

Looks like this didn't make it into a released version.

Note that you will also need to corresponding SYSINIT change, otherwise there will be a TDF error on reboot.