tztab on HP-UX help
Sébastien GODIER
I have just receive some HP J6000 Bi-cpu systems (very beautiful systems)
running HP-UX 11.00 .I'm a french resident and I would like to synchronize
there station with my NTP server (Linux box). But I have actually a timezone
problem. I would like to set the same timezone for PARIS in Linux (named
CET), but this one doesn't exist in tztab of the HP-UX system. Only
avalaible is Western Europe, but tztab informations don't concidere summer
and winter time for France. That why I would like to create myself the entry
for CET.
Did anybody know the syntax for create an entry in tztab ?
Many thanks.
Michael Piotrowski
> I have just receive some HP J6000 Bi-cpu systems (very beautiful systems)
> running HP-UX 11.00 .I'm a french resident and I would like to synchronize
> there station with my NTP server (Linux box). But I have actually a timezone
> problem. I would like to set the same timezone for PARIS in Linux (named
> CET), but this one doesn't exist in tztab of the HP-UX system. Only
> avalaible is Western Europe, but tztab informations don't concidere summer
> and winter time for France. That why I would like to create myself the entry
> for CET.
The time zone you want is called MEZ-1MESZ or MET-1METDST on HP-UX.
HTH
--
Michael Piotrowski, M.A. <m...@dynalabs.de>
David Dalton
: I have just receive some HP J6000 Bi-cpu systems (very beautiful systems)
First of all, you must understand that NTP operates on UTC (formerly GMT)
and knows nothing of timezones or summertime or any of that nonsense. You
can synch your client, in any timezone, with any NTP server in any
timezone, and the timezones will not matter to NTP at all. Everything is
UTC all the time.
On HP-UX there are three places that you set the timezone:
1. kernel parameter "timezone" (use SAM)
The units here are "minutes west of Greenwich", so -60 for you
2. /etc/TIMEZONE (sets default TZ environment variable for users)
You can edit this file by hand or run "/sbin/set_parms timezone"
and it will guide you through the process
3. TZ environment variable for each user
The users can set their own local variables
I really think that running set_parms can handle any concievable timezone,
but in case it cannot, surely one of these two will be equivalent to what
you want:
# Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit
MEZ-1MESZ
0 3 25-31 3 1983-2038 0 MESZ-2
0 2 24-30 9 1983-1995 0 MEZ-1
0 2 25-31 10 1996-2038 0 MEZ-1
# Middle European Time, Middle European Time Daylight Savings Time
MET-1METDST
0 3 25-31 3 1983-2038 0 METDST-2
0 2 24-30 9 1983-1995 0 MET-1
0 2 25-31 10 1996-2038 0 MET-1
--
-> My $.02 only Not an official statement from HP {They make me say that}
--
Our Most Frequent Question is: What is your most frequently asked question?
---------------------------------------------------------------------------
David Dalton dal...@cup.hp.deletethis.com 408/447-3016
Mikko Esaias Nahkola
>Sébastien GODIER (sebastie...@free.fr) wrote:
>
>: CET), but this one doesn't exist in tztab of the HP-UX system. Only
>: avalaible is Western Europe, but tztab informations don't concidere summer
>: and winter time for France. That why I would like to create myself the entry
>: for CET.
>: Did anybody know the syntax for create an entry in tztab ?
Well... man 4 tztab ??
>On HP-UX there are three places that you set the timezone:
>
>1. kernel parameter "timezone" (use SAM)
>
> The units here are "minutes west of Greenwich", so -60 for you
Can you use this for automatical DST adjustment by date? If so, how?
>2. /etc/TIMEZONE (sets default TZ environment variable for users)
>
> You can edit this file by hand or run "/sbin/set_parms timezone"
> and it will guide you through the process
This is what we use. See below.
>3. TZ environment variable for each user
>
> The users can set their own local variables
Yes, very handy... except when they forget that they've set it to
something non-default and then complain that it's broken.
>I really think that running set_parms can handle any concievable timezone,
>but in case it cannot, surely one of these two will be equivalent to what
>you want:
># Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit
>MEZ-1MESZ
># Middle European Time, Middle European Time Daylight Savings Time
>MET-1METDST
To this day I have never seen a HP-UX box be able to set a correct
timezone for Finland with set_parms as correct by the time of
delivery... every time a month early or late changing between summer and
winter time at least. Yes, the govt has changed it back and forth a
couple of times...
Just go and edit /usr/lib/tztab like we do... EET-2EETDST for us. On some
version of HP-UX, it was there but a month off changing the time, and on
some versions it was nowhere to be found...
Then be careful with patches that do stuff to tztab too, or you might
have to do it all over again.
--
Mikko Nahkola <mikko....@nokia.com>
My ideas, not my employer's. No warranty. YMMV.
#include <disclaimer.h>
David Dalton
: On 9 Jan 2001 22:30:48 GMT, David Dalton <dal...@cup.hp.com> wrote:
: >Sébastien GODIER (sebastie...@free.fr) wrote:
: >
: >1. kernel parameter "timezone" (use SAM)
: >
: > The units here are "minutes west of Greenwich", so -60 for you
: Can you use this for automatical DST adjustment by date? If so, how?
No, this parameter knows nothing of DST. It just sets the general location
of your system. Think of it as LONGITUDE, something that never varies.
DST is handled at the next level, which is /etc/TIMEZONE.
: >2. /etc/TIMEZONE (sets default TZ environment variable for users)
: >
: > You can edit this file by hand or run "/sbin/set_parms timezone"
: > and it will guide you through the process
: This is what we use. See below.
: >3. TZ environment variable for each user
: >
: > The users can set their own local variables
: Yes, very handy... except when they forget that they've set it to
: something non-default and then complain that it's broken.
Well, that's not really a problem that can be fixed by adjusting
something in HP-UX.
: To this day I have never seen a HP-UX box be able to set a correct
: timezone for Finland with set_parms as correct by the time of
: delivery... every time a month early or late changing between summer and
: winter time at least. Yes, the govt has changed it back and forth a
: couple of times...
I think you are saying that your local government has changed the dates for
summertime switch in recent years, maybe several times, and that
/usr/lib/tztab has not kept current. Many people do not realize that the
summertime switch is made at the pleasure of the local government, and the
legislators have done all sorts of crazy things over the years.
/usr/lib/tztab in an attempt to record this historical shifting and
approximate the current situation, but it is always a little behind.
That's why it was made very easy to edit /usr/lib/tztab and make your own
entries.
: Just go and edit /usr/lib/tztab like we do... EET-2EETDST for us. On some
: version of HP-UX, it was there but a month off changing the time, and on
: some versions it was nowhere to be found...
: Then be careful with patches that do stuff to tztab too, or you might
: have to do it all over again.
--
David Dalton
: To this day I have never seen a HP-UX box be able to set a correct
: timezone for Finland with set_parms as correct by the time of
: delivery... every time a month early or late changing between summer and
: winter time at least. Yes, the govt has changed it back and forth a
: couple of times...
PHCO_21690:
1. Timezone definitions for Australia,
Tasmania, New South Wales and Victoria
in /usr/lib/tztab are incorrect due to
new standards imposed for the Sydney
Olympics 2000 in Australia.
2. Finnish timezone definitions in
/usr/lib/tztab are incorrect from 1996
onwards.
Simon Waters
>
> On HP-UX there are three places that you set the timezone:
>
> 1. kernel parameter "timezone" (use SAM)
>
> The units here are "minutes west of Greenwich", so -60 for you
Silly question - but what is the point of setting this correctly. For as
long as the clock and and timezone are right. Is this just to make sure
things go wrong at the right time in January 2038?
> 2. /etc/TIMEZONE (sets default TZ environment variable for users)
>
> You can edit this file by hand or run "/sbin/set_parms timezone"
> and it will guide you through the process
>
> 3. TZ environment variable for each user
>
> The users can set their own local variables
>
> I really think that running set_parms can handle any concievable timezone,
> but in case it cannot, surely one of these two will be equivalent to what
> you want:
I doubt it - there is always one.
The TZ variable can accept really weird syntax if you need a temporary
fix for a change of Daylight saving (Summer time) rules - although HP
have always had patches ready for me.
Mikko Esaias Nahkola
>Mikko Esaias Nahkola (mnah...@localhost.localdomain) wrote:
>
>: To this day I have never seen a HP-UX box be able to set a correct
>: timezone for Finland with set_parms as correct by the time of
>: delivery... every time a month early or late changing between summer and
>PHCO_21690:
> 2. Finnish timezone definitions in
> /usr/lib/tztab are incorrect from 1996
> onwards.
Yes. I said "by the time of delivery" and that was released months after
we got our latest box.
And there is also such a thing as "OS level similarity" around here, and
that has to be maintained... to the patch level at least. We had enough
fun with PHSS_19739 on HP-UX 10.20 last time. Broke lots of stuff, that
one, and sure enough there was something that required it... and all
patches are considered equal by the bureaucracy.
Frank Slootweg
> David Dalton wrote:
>>
>> On HP-UX there are three places that you set the timezone:
>>
>> 1. kernel parameter "timezone" (use SAM)
>>
>> The units here are "minutes west of Greenwich", so -60 for you
>
> Silly question - but what is the point of setting this correctly. For as
> long as the clock and and timezone are right. Is this just to make sure
> things go wrong at the right time in January 2038?
timezone (*lower* case) and dst (see later) are mainly there for
historical (pre System V Release 4) reasons. Now (HP-UX 10.X and later)
they are only relevant for processes which are *not* (directly or
indirectly) started by rc(1M) (/sbin/rc). In most cases, these processes
are only some kernel processes, inittab(4) invoked getty(1M) processes
and init(1M) itself.
The kernel knows a little bit about DST. It only knows about (probably
outdated) USA, Australian and Western/Middle/Eastern "styles". See SAM'ss
help for 'details'.
[deleted]
Paul Christofanelli
: David Dalton wrote:
: >
: > On HP-UX there are three places that you set the timezone:
: >
: > 1. kernel parameter "timezone" (use SAM)
: >
: > The units here are "minutes west of Greenwich", so -60 for you
: Silly question - but what is the point of setting this correctly. For as
: long as the clock and and timezone are right. Is this just to make sure
: things go wrong at the right time in January 2038?
Simon has the right idea ... don't use this information, or rely on
this information. This is outdated, and would only be important for the
kernel anyway. And, you could argue that the kernel should really be
working in UTC and not even attempt to deal with local time. All of the
ctime(3C) routines that generate local time use TZ, none use the kernel
parameter. If TZ is not set, they default to US Eastern Time (don't
remember if that means EST5 or EST5EDT).
Programmatically, settimeofday(2), an undocumented system call, can
change this parameter from its compiled in default. This kernel
parameter manifests itself as 'tz_minuteswest', which is available from
the gettimeofday(2) system call. This is a non-standard, HP-UX only
extension to gettimeofday(2). Of course, it is always reset to the
compiled-in kernel parameter upon reboot.
Unfortunately, it appears that at one time, the login program defaulted
to the tz_minuteswest offset in the absence of a TZ variable. I don't
know if this is still the case; it had something to do with password
aging.
Set_parms' main problem with timezone is that the proper string may not
be listed for your country, which means that the timezone switch will
happen at the wrong time. A prime example of this, unfortunately again,
is for Finland -- set_parms names the timezone 'EET-2EEST', but tztab
names it 'EET-2EETDST'. So...the timezone switch back from daylight
time to standard time happens at 0200 daylight time (which becomes
0100) instead of 0400 becoming 0300, which is what the latest tztab
specifies. Timestamps on files are not affected, of course, but the
displayed time (by 'date', for instance) is not according to convention
for 2 hours. Probably not a huge deal...
-Paul C.
: > 2. /etc/TIMEZONE (sets default TZ environment variable for users)
Mark J. MacLennan
:
: Set_parms' main problem with timezone is that the proper string may not
: be listed for your country, which means that the timezone switch will
: happen at the wrong time. A prime example of this, unfortunately again,
: is for Finland -- set_parms names the timezone 'EET-2EEST', but tztab
: names it 'EET-2EETDST'. So...the timezone switch back from daylight
: time to standard time happens at 0200 daylight time (which becomes
: 0100) instead of 0400 becoming 0300, which is what the latest tztab
: specifies. Timestamps on files are not affected, of course, but the
: displayed time (by 'date', for instance) is not according to convention
: for 2 hours. Probably not a huge deal...
while the tztab file under HP-UX is an interesting idea (I don't
see it implemented in this way under other Unix systems), the
problem is that timezones around the world keep shifting and one
cannot rely upon the entries in this file - I am not even sure
that HP keeps this tztab file up-to-date with patches. Finland
was certainly one example but Argentina and Brazil, among locales,
also had changed their timezones over the past 6 months.
I'd just use /etc/TIMEZONE and make sure that there is not
equivalent entry in tztab (or remove them from the tztab file)
Have a took at http://www.twinsun/tz/tz-link.htm
or ftp://elsie.nci.nih/gov/pub
for current worldwide timezone information and TZ parameter settings.
- mark
Dennis Handly
: I'd just use /etc/TIMEZONE and make sure that there is not
: equivalent entry in tztab ...
: for current worldwide timezone information and TZ parameter settings.
That's the problem, it is the current settings for TZ. You need settings
that work for past years and for predictable future years. And possibly
many different timezones at the same time.
rksc...@gmail.com
rksc...@gmail.com
rksc...@gmail.com
MEZ-1MESZ
0 3 25-31 3 1983-2038 0 MESZ-2
0 2 24-30 9 1983-1995 0 MEZ-1
0 2 25-31 10 1996-2038 0 MEZ-1
MET-1METDST
0 2 24-30 9 1983-1995 0 MET-1
0 2 25-31 10 1996-2038 0 MET-1
Format : minutes, hour, days of month, month, range of years, actual day of the week where 0 is Sunday, then set time offset from Greenwich
to this value. When Unix arrives at these rules, the offset factor is applied to Unix time which is ALWAYS GMT...or UTC.
Example - 0 2 25-31 10 1996-2038 0 MET-1
"When it is 2am(2) in October(10), between the days of 25-31, and the years are 1996-2038, and it is Sunday(0), then set time to MET-1, which is Mediterranium Time minus 1 hour from Greenwich.
Bob