Brazil timezone issue

[Tony Kuehn]

I have a server in Brazil that I set the tztab on 3/01/05 so it is no longer in daylight savings (I was kinda late!). (see below end of /usr/lib/tztab) However, the system has switched from "BEST" time zone to "BEDT" so it is displaying time 2 hours behind UTC which is incorrect as it should be 3 hours behind UTC. This appears to have happened the first week on April. Can anyone explain why my system went into daylight savings time? (Note I do not have a new line at the end of the last line in the file not sure if that matters?)

BEST3BEDT
0 0 15-21 2 2003 0 BEST3
0 0 18-24 10 2003 0 BEDT2
0 0 14-20 2 2004 0 BEST3
0 0 1-2 11 2004 2 BEDT2
0 0 20-21 2 2005 0 BEST3

[Steven E. Protter]

In the absence of an ntp network time protocol connection your server should switch between times on a date known for your time zone when the OS was released.

The best way around that is to set the time zone and enable ntp to get actual time from a time server.

Another way to go is to set your systsem time to Greenwich mean time, if the users won't object.

http://www.ntp.org

SEP

[Tony Kuehn]

Stephen,
If I do a date -u I get the correct UTC time and we are using NTP. So I "beleive" that the time on the server is correct, however, it is displayed incorrectly because the timezone environment varialbe is set to daylight savings (BEDT). I am wondering why the timezone variable would have switched (without a reboot) and when the tztab config (above) is not configured to switch. Maybe I am confused about the tztab config?
Please advise, thanks!

[Ermin Borovac]

TZ environment variable should be set to BEST3BEDT. date command should show difference of 3 hours between UTC and your local time.

Format of lines in /usr/lib/tztab is

minute hour day_of_the_month month_of_the_year year day_of_the_week tzname_offset

minute: 0-59
hour: 0-23
day_of_the_month: 1-31
month_of_the_year: 1-12
year: 1970-2038
day_of_the_week: 0-6 (0 is Sunday)
tzname: BEST
offset: 3 hours behind UTC

According to your tztab, last change happened on Sunday February 20 2005, when difference between UTC and your local time became 3 hours.

Please note that kernel always keep its internal time in UTC. TZ variable only affects programs such as date etc.

[C. Beerse_1]

Some timekeeping details:

The system is never in some timezone, it should always run in 'epoc': number of seconds sinds 00:00, 1st january 1970. It is only the representation (the `date` command for example) that calculates to your current timezone. From `man date`: it is the ${TZ} environment variable that sets the timezone. See `man tztab` and `man environ` for details on how to control this.

The ntp-protocol and the ntp-deamon are there to keep the internal time (epoc) in sync with the rest of the world. Use `sam` to setup ntp. If you donnot have an ntp-server around and your internet-provider had none either, you can use 'pool.ntp.org', see http://www.pool.ntp.org/#use for details.

[Tony Kuehn]

Ermin,
The TZ variable is set to "BEST3BEDT". That is why I am so confused. The system continues to display the date/time as BEDT and 2 hour behind UTC. I have tried making changes to the tztab, however, have been unsuccessful to make it to display time in "standard time" for Eastern Brazil (3 hours behind UTC). Very strange. Well for now I have done a "set_parms timezone" and walked through the menu's so the time is now correctly displayed as 3 hours behind UTC, however, the TZ variable is now "SAT". I don't think the actual "string" in the TZ variable will affect anything as long as the time calculations "behind it" are correctly modifying the displayed time.
Thanks to all for your help!

[Ermin Borovac]

I was curious as to why it didn't work so I've tried it on my system.

BEST3BEDT
0 0 15-21 2 2003 0 BEST3
0 0 18-24 10 2003 0 BEDT2
0 0 14-20 2 2004 0 BEST3
0 0 1-2 11 2004 2 BEDT2
0 0 20-21 2 2005 0 BEST3

$ TZ=BEST3BEDT date; date -u
Fri May 27 02:41:56 BEDT 2005
Fri May 27 04:41:56 UTC 2005

When I changed the last two lines to include the range of 7 days (1-2 -> 1-7 and 20-21 -> 20-26) then it shows difference of 3 hours, which is correct.

0 0 1-7 11 2004 2 BEDT2
0 0 20-26 2 2005 0 BEST3

$ TZ=BEST3BEDT date; date -u
Fri May 27 01:48:16 BEST 2005
Fri May 27 04:48:16 UTC 2005

So I think it has a problem when day of the month range includes anything but 7 days.