Search

October 22, 2012

Marking Time with MPE's TZTAB File

By Gilles SchipperGSA Associates

Last in a series

Twelve days from today, Daylight Saving Time ends and will give HP 3000 users a reason to look at their clocks. This week may be an appropriate time to think about implementing some best practices associated with clock maintenance for the HP 3000s that you administer. One special nuance for MPE administrators is the TZTAB file. It's code that turns out to be important to third-party and independent software on your system.

TZTAB file and SETVAR TZ

In other installments in this series, I mentioned the TZTAB file and TZ variable and their relevance to popular third-party software suites. Although not utilized by MPE, by and large, this file and variable are important for some widely-used software.

And, due to a relatively recent change to the universal TZTAB file required to accommodate the new Daylight Savings rules effective in 2007, it's useful to understand the quite simple format of the TZTAB file, and the corresponding TZ variable that points to its appropriate location in the file.

Let's illustrate by using Aleutian Time (Hawaii) as an example. The TZTAB file (which is located in the LIB.SYS group), contains:

Let's repeat the portion below that is associated with Aleutian Standard Time. We'll add a reference number at the beginning of each line.

1. # Aleutian Standard Time, Aleutian Daylight Time (US)

2. AST10ADT

3. 0 3 24-30 4 1970-1973 0 ADT9

4. 0 3 6 1 1974 0-6 ADT9

5. 0 3 22-28 2 1975 0 ADT9

6. 0 3 24-30 4 1976-1986 0 ADT9

7. 0 3 1-7 4 1987-2006 0 ADT9

8. 0 3 8-14 3 2007-2038 0 ADT9

9. 0 1 25-31 10 1970-1973 0 AST10

10. 0 1 24-30 11 1974 0 AST10

11. 0 1 25-31 10 1975-2006 0 AST10

12. 0 1 1-7 11 2007-2038 0 AST10

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day (0 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock, aka Greenwich Mean Time(GMT)).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14 3 2007-2038 0 ADT9

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 9 hours from UTC (numeric part of seventh field).

Which means nothing for Hawaii, since Hawaii does NOT adhere to Daylight Savings Time.

One more thing: The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7 11 2007-2038 0 AST10

means:

The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 10 hours removed from UTC. Again, since Hawaii does not adhere to Daylight Savings Time, no actual adjustment is necessary.

Let's use another example, using Eastern Time. The relevant portion of the TZTAB file is:

1. # Eastern Standard Time, Eastern Daylight Time

2. EST5EDT

3. 0 3 24-30 4 1970-1973 0 EDT4

4. 0 3 6 1 1974 0-6 EDT4

5. 0 3 22-28 2 1975 0 EDT4

6. 0 3 24-30 4 1976-1986 0 EDT4

7. 0 3 1-7 4 1987-2006 0 EDT4

8. 0 3 8-14 3 2007-2038 0 EDT4

9. 0 1 25-31 10 1970-1973 0 EST5

10. 0 1 24-30 11 1974 0 EST5

11. 0 1 25-31 10 1975-2006 0 EST5

12. 0 1 1-7 11 2007-2038 0 EST5

Line 1 is simply a comment line (#) in column 1, that identifies the common reference to the time zone

Line 2 is the actual value that the TZ variable needs to be set to for many Unix/Posix/Linux commands that need a time-reference to work properly.

All subsequent lines represent specific fields that have meaning according to their positional ordinal.

The first value (which is 0 in all lines) represents the minute of the hour.

The second value represents the hour of the day (1 or 3 in all lines)

The 3rd value represents the day or day-range in the month.

The 4th value represents the month.

The 5th value represents the year or year-range.

The 6th value represents the day of the week (Sunday=0).

The 7th value is a string that represents the time zone adjustment in the form tznameDIFF, where "tzname" matches the first or last 3 characters of the TZ variable in line 1, and the DIFF represents the number of hours offset from UTC (Universal Time Clock).

In the above example, since only lines 8 and 12 apply to the current (and all future known) years, I will translate each of the 2 lines:

0 3 8-14 3 2007-2038 0 EDT4

On Sunday (6th field = 0), March (4th field=3) 11 (3rd field = 8-14), the first minute of the adjusted time will take place at 03:00 (fields 2 and 1, respectively), the adjustment resulting in the time being 4 hours from UTC (numeric part of seventh field).

The above line suggests that the time adjustment BEGIN at 2:00AM, since the first minute of the ADJUSTED TIME should be 03:00 AM - which is exactly what happens when the time is moved forward one hour at 2am.

So, using the example above, we can see that:

0 1 1-7 11 2007-2038 0 EST5

means: “The first minute of the adjusted time will be at 1:00am on whichever day in November (1 thru 7) falls on a Sunday, in the years 2007 thru 2038. The adjusted time will be 5 hours removed from UTC.”

Using these examples, you can construct your own TZTAB.LIB.SYS file that satisfies the requirements of your particular HP 3000 system.

The bottom line to all of this: The TZTAB.LIB.SYS file, in conjunction with the TZ variable, is utilized by the MPE Posix environment, as well as some third-party software suites -- if and when necessary to accommodate GMT and local times.

If you can't find copies of NTPDATE or the TZTAB file, send me a request by email (gilles@gsainc.com) and I will send you a copy of both in a single Reflection-label storefile format file. Thanks to Mark Ranft and Jeff Kell for assistance in acquiring these files.

Comments

Marking Time with MPE's TZTAB File

By Gilles SchipperGSA Associates

Last in a series

Twelve days from today, Daylight Saving Time ends and will give HP 3000 users a reason to look at their clocks. This week may be an appropriate time to think about implementing some best practices associated with clock maintenance for the HP 3000s that you administer. One special nuance for MPE administrators is the TZTAB file. It's code that turns out to be important to third-party and independent software on your system.

TZTAB file and SETVAR TZ

In other installments in this series, I mentioned the TZTAB file and TZ variable and their relevance to popular third-party software suites. Although not utilized by MPE, by and large, this file and variable are important for some widely-used software.

And, due to a relatively recent change to the universal TZTAB file required to accommodate the new Daylight Savings rules effective in 2007, it's useful to understand the quite simple format of the TZTAB file, and the corresponding TZ variable that points to its appropriate location in the file.