Problems with the Timezone
Marvin Garcia
Time Server and I think it is working fine, but the problem is with the
Timezone. My timezone is GMT-4, but when I configured the servers they
change the time, and then I had to change the GMT-4 to GMT+4 in order
they reflect the correct time.
The servers I'm using are:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
server pool.ntp.org
Do you think is there something I could do to solve this problem?
Thanks for your help,
David J Taylor
> Hello, I'm trying to configure some Solaris Server to your NTP Pool
> Time Server and I think it is working fine, but the problem is with
> the Timezone.
You should configure your system so that internally it works in UTC, but
the time is presented (should you wish) in your local time.
In Windows, this is accomplished with a Control Panel applet, but I don't
know the equivalent Solaris commands.
NTP itself works purely in UTC.
David
Marvin Garcia
but now with an external one, i having this problem. I know NTP works
in UTC, but what i dont understand is why if the servers have GMT-4 as
my local time they display another time not the rigth one, and with
GMT+4 they display the rigth time, but GMT+4 is not the correct one for
my location.
Your comments and ideas are important to me. Thanks
Martin Burnicki
Please run the commands
date; date -u
on your system and let us know which of the displayed times is correct.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
Marvin Garcia
root@snbntp0201 # echo $TZ
GMT-4
root@snbntp0201 # date; date -u
Wed May 10 19:35:04 GMT 2006
Wed May 10 15:35:04 GMT 2006
What i mean is that instead of subtract 4 it sum 4 to the GMT ... Do
you see the diferences?
I think this is ilogical or am i doing something wrong?
Martin Burnicki
Yes, you're thinking wrong about the TZ variable. The first 3 letters (in
your case GMT) should be an abbreviation of your local time zone name.
The following number is the UTC offset from your local standard time, in
your case: UTC = (local time) -4 hours.
A 3rd field of letters may be appended to indicate that daylight saving time
(DST) is currently in effect and thus there's an additional offset to take
into account. For my system here (located in Germany) I get the following:
# date -u
Wed May 10 16:06:21 UTC 2006 # This is the current UTC time
# TZ=CET-1 date
Wed May 10 17:06:21 CET 2006 # My standard local time
# TZ=CET-1CST date
Wed May 10 18:06:21 CST 2006 # My local time when DST is effective
Please note that this notation is very old. There have been extensions to
this which define automatically beginning and end of DST, and current OS
versions often use a timezone/zoneinfo/tz database which lets you select
your current local time zone and also provides information of beginning/end
of DST in the past. The latter lets you select a time zone like
Europe/Berlin or similar. Please refer to your operating system manual on
how to select your time zone properly.
Anyway, if your ntpd syncs to internet NTP time servers which work correctly
and changes time if you use your local refclock then there seems to be
something wrong with your local refclock configuration, at the device or in
ntp.conf.
Richard B. Gilbert
NTP does not deal with local time at all. It's UTC all the way.
The display of local time is up to your operating system. You say your
time zone is GMT-4, do you mean that you are on Eastern Daylight Time?
GMT+4 puts you four hours east of Greenwich.
Try saying "echo $TZ". What response do you get?
Say "date -u". What response do you get?
Say "date". What response?
Marvin Garcia
server 0.north-america.pool.ntp.org
server 1.north-america.pool.ntp.org
server 2.north-america.pool.ntp.org
broadcast 224.0.1.1 ttl 4
enable auth monitor
driftfile /var/ntp/ntp.drift
statsdir /var/ntp/ntpstats/
filegen peerstats file peerstats type day enable
filegen loopstats file loopstats type day enable
filegen clockstats file clockstats type day enable
keys /etc/inet/ntp.keys
trustedkey 0
requestkey 0
controlkey 0
Look this again
root@snbntp0201 # date
Wed May 10 21:41:57 GMT 2006
root@snbntp0201 # date -u
Wed May 10 17:42:00 GMT 2006
root@snbntp0201 # echo $TZ
GMT-4
if you see my timezone var is set to GMT-4 (this is the one that
belongs to me location). the system date (Wed May 10 21:41:57 GMT
2006) should be (Wed May 10 17:42:00 GMT 2006) - 4 = Wed May 10
13:42:00 GMT 2006 not (Wed May 10 17:42:00 GMT 2006 )+ 4 = Wed May 10
21:41:57 GMT 2006, because my GMT is set to GMT-4.
Richard B. Gilbert
GMT-4 is, I believe, the NAME of a time zone. I have no idea how the
name was arrived at but it has nothing to do with subtracting 4 from GMT
to get local time.
I think what you really want for your timeline is "US/Eastern". That
will give you minus 4 while daylight savings time is in effect a nd
minus 5 when we return to standard time.
Marvin Garcia
GMT-4
# date -u
Wed May 10 18:26:01 GMT 2006
# date
Wed May 10 22:26:03 GMT 2006
Richard B. Gilbert
> # echo $TZ
> GMT-4
>
> # date -u
> Wed May 10 18:24:36 GMT 2006
>
> # date
> Wed May 10 14:25:00 EDT 2006
>
All right. What were you complaining about again? I thought you said
earlier that GMT-4 was adding four hours instead of subtracting.
And let's really get down to the basics. Where are you located? If you
are in the eastern United States, GMT-4 will probably not do the right
thing when we switch back to standard time next October.
I run Solaris 8 and Solaris 9 systems in New Jersey and my TZ
environment variable is set to "US/Eastern". I've never had a problem
with it. The naming seems quite clear.
Marvin Garcia
# echo $TZ
GMT-4
# date -u
# date
Wed May 10 22:26:03 GMT 2006
See the diference now? the GMT-4 is still adding four hours instead of
subtracting.
I'm in Dominican Republic, here we use GMT-4
i try with "US/Eastern" and it work, but here we dont need daylight
time. So the correct timezone is GMT-4.
Marvin Garcia
Richard B. Gilbert
I just run sys-unconfig on one of my test systems and reconfigured it!
Solaris system setup lets you pick your time zone from a list. I picked
"America" from the first list and was presented with a second list
which contained "Dominican Republic".
Try "America/Santo_Domingo" as your time zone. It works for me.
Now I've got to go back and run sys-unconfig again!
Marvin Garcia
the results,
Thanks
Martin Burnicki
Marvin Garcia wrote:
> This is what i have en the ntp.conf file.
[...]
Looks OK.
> Look this again
> root@snbntp0201 # date
> Wed May 10 21:41:57 GMT 2006
> root@snbntp0201 # date -u
> Wed May 10 17:42:00 GMT 2006
> root@snbntp0201 # echo $TZ
> GMT-4
>
> if you see my timezone var is set to GMT-4 (this is the one that
> belongs to me location). the system date (Wed May 10 21:41:57 GMT
> 2006) should be (Wed May 10 17:42:00 GMT 2006) - 4 = Wed May 10
> 13:42:00 GMT 2006 not (Wed May 10 17:42:00 GMT 2006 )+ 4 = Wed May 10
> 21:41:57 GMT 2006, because my GMT is set to GMT-4.
As already mentioned in my other post, the old TZ thing works exactly the
other way round. If your local time is GMT - 4 hours (or let's better call
it UTC - 4 hours) then you must set the TZ environment variable to GMT4
because the definition is UTC = local time + TZ value. Just try:
date -u # returns UTC time
TZ=GMT4 date # displays UTC time - 4 hours
On my system is looks like this:
# date -u
Wed May 10 19:57:38 UTC 2006
# TZ=GMT4 date
Wed May 10 15:57:40 GMT 2006
I think the result is what you expect. However, "GMT" is a poor choice for
the abbreviation of the time zone name since it implies that the displayed
time is GMT, which in fact it isn't. Better use a abbreviation which is
associated to what you call your local time zone.
Anyway, using TZ this way is outdated and you should preferably configure
your time zone maybe as "America/Santo_Domingo", as Richard B. Gilbert
proposed in one of his posts.
Marvin Garcia
Richard said.
Thank u guys for your help and support.
Marvin Garcia
Marvin Garcia
GMT4 is working now. (but it is doing the funtion of GMT-4?)
But the two types of formats i knew were GMT- # or GMT+ # (For GMT
timezones)
what if i want to add instead of subtract?
what do you mean with the old TZ thing works exactly the
other way round? and why?
Martin Burnicki
> as you see i'm new in solaris so in NTP.
>
> GMT4 is working now. (but it is doing the funtion of GMT-4?)
>
> But the two types of formats i knew were GMT- # or GMT+ # (For GMT
> timezones)
>
> what if i want to add instead of subtract?
Obviously you must then use -4, as you did first.
Please, didn't you read my earlier posts carefully?
> what do you mean with the old TZ thing works exactly the
> other way round? and why?
I've already explained that GMT-4 is not correct for you since it doesn't
mean your local time is GMT - 4 hours. GMT should by replaced by some other
3 letter code which is an abbreviation of the name of the time zone you're
in, e.g for Central Europe it would be CET.
The number following the 3 letters indicates the time offset between UTC and
local time, which could be specified (for your location):
your local time = UTC - 4 hours, or,
UTC = your local time + 4 hours
That's what I meant vy "the other way round". You thought you had to take
the number from the first equation, but in fact you have to take the number
from the second equation.
Maybe this is due to the old days where computers didn't have a real time
clock, so after reboot, the admin had to enter the current date and time,
which he did according to his local time zone, and the the OS computed UTC
time base on the value in the TZ variable, in your case
UTC = your local time + 4 hours.
Darren Dunham
Note the problem you get when configuring your system this way. Even
though corrections are applied, it reports your timezone as 'GMT'.
That's very confusing.
Please use US/Eastern or another appropriate timezone so that the
displayed time doesn't say 'GMT', yet apply an offset.
--
Darren Dunham ddu...@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
Chris Davies
> I think what you really want for your timeline is "US/Eastern".
Not for the Dominican Republic it isn't. The correct timezone label
(confirmed to work on Solaris) is America/Santo_Domingo.
$ date # British Summer Time
Thu May 11 10:33:26 BST 2006
$ date -u # UTC
Thu May 11 09:33:26 GMT 2006
$ TZ=America/Santo_Domingo date # Dominican Republic
Thu May 11 05:33:26 AST 2006
Chris
Marvin Garcia
But what i dont get is why with a local reference clock i always used
GMT-4 in solaris and even in windows has always work fine with GMT-4.
But now that we decided to change to a external reference clock the
timezone have to change. that's what i dont now why?
Martin Burnicki
Yet we've discussed how to make your operating system behave as expected.
As I already mentioned before, if your OS' time steps when you let it
synchronize to your local refclock instead of the internet time servers
then we should find out why this happens. I'm assuming it is due to the
configuration of your refclock, or due to your configuration of ntpd for
that refclock.
A little bit more information about the type of your refclock and how you
have configured ntpd for that clock would really be helpful.
David Woolley
Marvin Garcia <marv...@gmail.com> wrote:
> But what i dont get is why with a local reference clock i always used
> GMT-4 in solaris and even in windows has always work fine with GMT-4.
> But now that we decided to change to a external reference clock the
> timezone have to change. that's what i dont now why?
Probably because your machine's time was completely broken before but
you never noticed, because you never had something with a correct
timestamp. GMT-4 is doubly broken; GMT is only suitable for zero
offsets, and because the sign is wrong.
Old style Unix time zone codes almost certainly use positive numbers for
the USA because Bell Labs was in the USA. On the other hand, the proper
international standard uses negative numbers for the USA.
Also, the old style timezone codes DO NOT contain the string GMT, unless
the standard time is GMT. GMT is ALWAYS followed by 0.
Examining the (rather dated) Olsen timezone data that I have, you are
fortunate that you haven't used daylight saving time since January 1974
(although there was a time in Autumn 2000 when you were on the +0500
timezone). That means one doesn't have to worry about simple timezone
codes assuming obsolete US legislation.
Your correct, old style, Unix timezone code is AST4, assuming that there
have been no more glitches since 2000-12-03T06:00:00Z. AST4 should work
on even the oldest of Unices. America/Santo_Domingo only works on those
that have the Olsen package (e.g. not on standard SCO Openserver).
PS Could you please not post three copies of everything; it makes a
mess of threading.
PPS, for the person who said that XXX9 is a name. It's not. It's
a code that is interpreted by the time libraries. E.g. XXX9 is
completely fictious, but still works:
$ date -u
Thu May 11 21:11:46 UTC 2006
$ TZ=XXX9 date
Thu May 11 12:11:56 XXX 2006
Per Hedeland
(David Woolley) writes:
>In article <1147351652....@j73g2000cwa.googlegroups.com>,
>Marvin Garcia <marv...@gmail.com> wrote:
>
>> But what i dont get is why with a local reference clock i always used
>> GMT-4 in solaris and even in windows has always work fine with GMT-4.
>> But now that we decided to change to a external reference clock the
>> timezone have to change. that's what i dont now why?
>
>Probably because your machine's time was completely broken before but
>you never noticed, because you never had something with a correct
>timestamp. GMT-4 is doubly broken; GMT is only suitable for zero
>offsets, and because the sign is wrong.
Hm, well, I'd say it was because he never looked at the actual system
time, only the local time displayed by 'date', 'ls', etc. Ignoring the
zone designation, his hours/minutes/seconds were correct - but the
system time, which should be UTC, was actually 8 hours off from UTC.
>Old style Unix time zone codes almost certainly use positive numbers for
>the USA because Bell Labs was in the USA. On the other hand, the proper
>international standard uses negative numbers for the USA.
I think the proper international standard for the TZ variable is POSIX,
about which the Olsen time zone data files (which are fascinating
reading btw:-) has this to say:
# We use POSIX-style signs in the Zone names and the output abbreviations,
# even though this is the opposite of what many people expect.
# POSIX has positive signs west of Greenwich, but many people expect
# positive signs east of Greenwich. For example, TZ='Etc/GMT+4' uses
# the abbreviation "GMT+4" and corresponds to 4 hours behind UTC
# (i.e. west of Greenwich) even though many people would expect it to
# mean 4 hours ahead of UTC (i.e. east of Greenwich).
This is in the 'etcetera' file, which defines zones that are
sort-of-like the "raw" TZ code:
$ TZ=XXX-4 date
Fri May 12 04:03:37 XXX 2006
$ TZ=Etc/GMT-4 date
Fri May 12 04:03:46 GMT-4 2006
Anyway, the problem isn't really with the sign - after all, giving "the
number of hours you need to add to local time to get UTC" makes just as
much sense as giving "the number of hours you need to add to UTC to get
local time" - but (as you say) with the weird idea of combining the
"GMT" string with the offset, making it "look like" something that
should be added to GMT, and (for the "raw code") giving a bogus zone
designation in 'date' output. I wonder where that comes from...
--Per Hedeland
p...@hedeland.org
Marvin Garcia
have been answred.
Now i see that unix for localtime configured
for files in /usr/share/zoneinfo/ are inversed (GMT-Number act as
GMT+Number, and GMT+Number work like GMT-Number) this cause bad
date to be written to log files and causes the system to run
maintanance
tasks out of sync with other systems (database shutdown, by instance),
causing availability problems for systems running in production
environment,
backup problems, etc.