Timezone rule for MET

[Michael Menge]

OpenVMS 8.3
The logical name SYS$TIMEZONE_RULE for timezone MET shows
"MET-1MEST-2,M3.4.0/02,M10.4.0/03".
Since we change to summer-/wintertime on the last sunday of march/october, should it be
"MET-1MEST-2,M3.5.0/02,M10.5.0/03", because both months could have 5 sundays ?

[Martin Vorlaender]

Michael,

yes, it should indeed say "5" instead of "4". This error has been in there so long,, I can't believe it that they haven't fixed it yet.

cu,
Martin

[Bart Zorn_1]

I have been struggling with this before.

The whole time zone rule system has an incredible high Unix rate. I wonder how it is possible that Unix can make something out of it.

Anyway. It appears that the rule that you expect to see, is the rule that is used to generate the rule that applies at this moment. After each DST change, the rule is calulated again, using the first rule. Sjeees!

I had better not elaborate any further ...

Bart Zorn

[Wim Van den Wyngaert]

Isn't Germany the same as Belgium ? That is CET ? The "5" means last. Typical Unix style.

But now I find MET on my systems too. March 2008 we will be in trouble because the 4th Sunday is incorrect.

Wim

[Wim Van den Wyngaert]

10 for Bart.

Just found the same : in the dtss$utc_startup.com we initialize dtss with 5 instead of 4. The name MET is bad (I think) but it doesn't matter. The rule matters, not the name assigned to it.

Wim

[Wim Van den Wyngaert]

Central European Time (or Central Europe Time) used to be also known under other names, such as Middle European Time (today the MET abbreviation should be used to mean Middle Eastern Time) and in the past Berlin Time.

What a mess !

Wim

[Martin Vorlaender]

I decided to dig a little deeper. So I looked into the VMS FAQ ( http://64.223.189.234/vmsfaq/vmsfaq_005.html#timezic
), and then into SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]EUROPE.
Oh wonder - the information in there is correct! (see attached)

So I decided to re-compile:

$ zic europe.

and re-select my timezone in SYS$MANAGER:UTC$TIME_SETUP.COM

$ SHOW LOG /SYS SYS$TIMEZONE*
"SYS$TIMEZONE_RULE" = "CET-1CEST-2,M3.4.0/02,M10.4.0/03"

:-((

Perhaps zic didn't put the result in the right place:

$ zic -d "/SYS$common/SYS$ZONEINFO/SYSTEM" europe.
$ @SYS$MANAGER:UTC$TIME_SETUP.COM
...
$ SHOW LOG /SYS SYS$TIMEZONE*
"SYS$TIMEZONE_RULE" = "CET-1CEST-2,M3.4.0/02,M10.4.0/03"

Does anyone have a hint on what I missed?

cu,
Martin

[Wim Van den Wyngaert]

Martin,

See answer Bart ?

Wim

[Ian Miller.]

Martin,
see recent postings by The Hoff on the use of zic on the new hoffmanlabs site.

[Martin Vorlaender]

Ian,

the steps Hoff outlines are exactly those that I executed.

BTW: the system I tried this on is an OpenVMS I64 8.2-1. NET$DISABLE_DTSS _is_ defined on that system.

cu,
Martin

[Hoff]

There was a change "upstream" in the TZ file in the case of the existing US rules, and it was overrunning the end date for the rules.

In the case of the US rules, I posted up a second existing line in the US rules that needed a correction; it needs to have a "max" switched to a 2006 end-date.

This oddity showed up with zdump. (You'll have to port over zdump if you want a look at "why" the rules produce a particular result. The zdump port isn't difficult. Why it's not already shipped with OpenVMS is fodder for another discussion.)

I haven't looked at MET in V8.3, but MET is now Middle Eastern Time, and not Middle European Time. I don't know which rules are present in V8.3, but I'd tend to expect the rules are Middle Eastern Time -- I don't know whether or not the V8.3 rules reflect the zone name change from Middle European to Middle Eastern, but I'd tend to expect they do reflect the change. It was a while back that the MET change was made.

The three-letter TZ names have traditionally featured a degree of ambiguity. That's why you can tend to see "US/Eastern" used, for instance.

Stephen Hoffman
HoffmanLabs

[Michael Menge]

As Martin wrote in his attachment:
CET and MET have both rule C-Eur.
When looking in SYS$COMMON:[SYS$ZONEINFO.SYSTEM.SOURCES]*.* you only find MET in file EUROPE.

[Martin Vorlaender]

Hoff,

following your advice, I got myself the zdump sources from http://cvsweb.de.netbsd.org/cgi-bin/cvsweb.cgi/src/lib/libc/time/zdump.c?rev=HEAD . After a few tweaks, I have a clean compile. According to zdump, everything's okay:

$ mcr []zdump -v -c 2009 cet
...
cet Sun Mar 30 00:59:59 2008 UTC = Sun Mar 30 01:59:59 2008 CET isdst=0
cet Sun Mar 30 01:00:00 2008 UTC = Sun Mar 30 03:00:00 2008 CEST isdst=1
cet Sun Oct 26 00:59:59 2008 UTC = Sun Oct 26 02:59:59 2008 CEST isdst=1
cet Sun Oct 26 01:00:00 2008 UTC = Sun Oct 26 02:00:00 2008 CET isdst=0

But the SYS$TIMEZONE* logicals are still wrong:

"SYS$TIMEZONE_DAYLIGHT_SAVING" = "1"
"SYS$TIMEZONE_DIFFERENTIAL" = "7200"
"SYS$TIMEZONE_NAME" = "CEST"
"SYS$TIMEZONE_RULE" = "CET-1CEST-2,M3.4.0/02,M10.4.0/03"

cu,
Martin

[Hoff]

Can you show the zdump for 2006 through 2009?

And after the zic and replacement and the subsequent invocation of:

@SYS$MANAGER:UTC$TIME_SETUP

What TZ did you select? The rules shown in the logical name seem to align with an African CET/CEST definition. (I'm looking at a set of V7.3-1 rules right now, and not at the V8.3 rules.)

With V8.3, try downloading the rules from ftp://elsie.nci.nih.gov/pub/ and issuing the zic -- you may well have a version of zic new enough to build the current "real" timezone rules. (What I've posted is for older releases.) I'd also DIFF the old and new files for changes, just for grins.

[Martin Vorlaender]

>>>
Can you show the zdump for 2006 through 2009?
<<<

I will as soon as I'm back at the system (i.e. tomorrow afternoon UTC+0100).

>>>
And after the zic and replacement and the subsequent invocation of:

@SYS$MANAGER:UTC$TIME_SETUP

What TZ did you select? The rules shown in the logical name seem to align with an African CET/CEST definition.
<<<

CET, which I thought stands for Central European Time. Just to be complete, I also tried with Europe/Berlin, which gives the same results WRT the SYS$TIMEZONE_RULE.

>>>
With V8.3, try downloading the rules from ftp://elsie.nci.nih.gov/pub/ and issuing the zic -- you may well have a version of zic new enough to build the current "real" timezone rules. (What I've posted is for older releases.) I'd also DIFF the old and new files for changes, just for grins.
<<<

See above. I will, and get back with the results.

cu,
Martin

[Sebastian Bazley]

BTW, the command file SYS$MANAGER:UTC$TIME_SETUP.COM has a SHOW option which (on VMS 7.3-2 at least) translates the cryptic string for the current year:

=======================
$ @SYS$MANAGER:UTC$TIME_SETUP.COM SHOW

[...]

TIME ZONE RULE = GMT0BST-1,M3.4.0/01,M10.4.0/02
Change GMT to BST on the Fourth Sunday of March (25-Mar-2007) at 01:00
Change BST to GMT on the Fourth Sunday of October (28-Oct-2007) at 02: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
=======================

[Wim Van den Wyngaert]

But it shows the same timezone rule as in sys$timezone_rule. Thus not correct. At least when you use dtss.

Wim

[Martin Vorlaender]

So, here we go again...

>>>
Can you show the zdump for 2006 through 2009?
<<<

Please see attached.

>>>
With V8.3, try downloading the rules from ftp://elsie.nci.nih.gov/pub/ and issuing the zic -- you may well have a version of zic new enough to build the current "real" timezone rules. (What I've posted is for older releases.) I'd also DIFF the old and new files for changes, just for grins.
<<<

Please see attached.

Interesting enough, when I compiled zic from elsie's tzcode archive, I got differences in the timezone files. But when I installed them, UTC$TIME_SETUP would not find any daylight savings time for that time zone (please see attached).

It could well be that my newly built zic isn't complete, because building it is more involved than I thought, but I had a clean compile & link.

cu,
Martin

[Sebastian Bazley]

As an experiment I tried changing the SYS$TIMEZONE_RULE logical to M10.5.0 (this can be done at process level)

The SHOW function does not like it:

LOCAL TIME ZONE = GB-EIRE -- DAYLIGHT TIME
LOCAL SYSTEM TIME = 28-MAR-2007 15:34:50.12 (BST)
TIME DIFFERENTIAL FACTOR = 1:00
TIME ZONE RULE = GMT0BST-1,M3.4.0/01,M10.5.0/02
Change GMT to BST on the Fourth Sunday of March (25-Mar-2007) at 01: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

Looks like there are some bugfixes needed ...

[Sebastian Bazley]

Looks like you may need to revert to OpenVMS ALPHA V6.2 to get the correct European TimeZones...

See the ALPTZ01_062 patch from 2006/11/16:

http://www5.itrc.hp.com/service/patch/patchDetail.do?patchid=ALPTZ01_062&sel={openvms:alpha:6.2-1h3,}&BC=main|search|

which contains the following notes:

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

The following timezones have been changed:

[...]

TZ Subregion: GB-Eire
Existing Rule: GB-Eire GMT0BST-1,M3.5.0/1,M10.5.0/1
Changed Rule: (US DST Extension): GMT0BST-1,M3.5.0/1,M10.5.0/2

TZ Subregion: WET
Existing Rule: WET0WET_DST-1,M3.5.0/1,M9.5.0/1
Changed Rule: WET0WEST-1,M3.5.0/1,M10.5.0/2

[...]

TZ Subregion: MET
Existing Rule: MET-1MET_DST-2,M3.5.0/2,M10.5.0/3
Changed Rule: MET-1MEST-2,M3.5.0/2,M10.5.0/3

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

Sometimes old is best!

[H_Bachner · Accepted solution]

When SYS$TIMEZONE_RULE is set, the calculation always reflects the situation in the year in question. As the last Sunday in October 2007 is the fourth Sunday, you see "M10.4.0/03" in the rule logical. In a year with five Sundays in October, the logical name will show "M10.5.0/03".

The same is true for the time switch in spring, of course.

Hans.

[Martin Vorlaender]

Ouch!

Hans seems to be on the point (see attached).

This is so wierd that I'm not going to follow it up any further...

cu,
Martin

[Michael Menge]

The *TIMEZ* logicals change without calling @UTC$TIME_SETUP; after setting the time to "1-jan-2008 10:19", the logicals show the correct values for this date and year.
But when you go back to "29-mar-2007 10:19",
the logicals don't go back to the former values. You have to call @UTC$TIMNE_SETUP.

[Tanner_4]

Hi

we have two different issues here.
first:
the change of the meaning for the abbreviation MET was used for Middle European Time and is now Middle Eastern Time.
see http://en.wikipedia.org/wiki/Central_European_Time for some details

second:
the fuzzy implementation of the time zone rule in OpenVMS.
The logical name (SYS$TIMEZONE_RULE)must reflect the exact occurance of day for the change.
For example M3.4.0 is the fourth (4) sunday (0) of march (3) and M10.5.0 is the fifth (5) sunday (0) of october (10).
But the rule says:
1 = first
2 = second
3 = third
4 = fourth
5 = LAST (this means the fourth or fifth)
The code for the time change on OpenVMS (native or with DTSS) does not honor the five as the LAST it expects a 4 if we have four (sundays) or a 5 if we have five to work properly.
@SYS$MANAGER:UTC$TIME_SETUP.COM SHOW
has the same problem if the logical does not reflect the correct setting for the current year.
Therefore the logical is recalculated short after beginning of the new year by a TQE for the job controller.

regards peter