SEO

Hi,

I'm trying to fix things for the upcoming Daylight Savings Time
change. We're using a rather old Red Hat Linux system. (Please, no
questions about why we haven't upgraded.)

A couple of places recommended downloading the timezone files from
ftp://elsie.nci.nih.gov/pub/ and running zic on the files, but I'm not
sure it worked right. I don't know if I did something wrong, or if
I'm wrong to expect different output from what I'm getting...

I went to that site and downloaded and unpackaged tzcode2007c.tar.gz
and tzdata2007c.tar.gz. First, in tzcode2007c, I did a "make" to
rebuild zic and zdump. (It complained about yearistype.sh not being
found in tzcode2007c, so I symlinked the one I found in tzdata2007c
and continued.) Then, in tzdata2007c, I tried to run zic on the
files, using the zic I just built. All the files except three,
iso3166.tab, zone.tab, and yearistype.sh, looked like source files for
zic, so I ran it with a command like this:

zic -d mytestdir [a-f]* [l-s]*

to pick up all the files except for those three. The result was a
bunch of files and subdirectories being created in mytestdir.

But then I ran the zdump I just built on the PST8PDT file that zic
just created:

zdump -v mytestdir/PST8PDT

The portion of the output for the years 2006 through 2008 looked like
this:

PST8PDT Sun Apr 2 09:59:59 2006 UTC = Sun Apr 2 01:59:59 2006 PST
isdst=0
PST8PDT Sun Apr 2 10:00:00 2006 UTC = Sun Apr 2 03:00:00 2006 PDT
isdst=1
PST8PDT Sun Oct 29 08:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 PDT
isdst=1
PST8PDT Sun Oct 29 09:00:00 2006 UTC = Sun Oct 29 01:00:00 2006 PST
isdst=0
PST8PDT Sun Apr 1 09:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 PST
isdst=0
PST8PDT Sun Apr 1 10:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 PDT
isdst=1
PST8PDT Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT
isdst=1
PST8PDT Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST
isdst=0
PST8PDT Sun Apr 6 09:59:59 2008 UTC = Sun Apr 6 01:59:59 2008 PST
isdst=0
PST8PDT Sun Apr 6 10:00:00 2008 UTC = Sun Apr 6 03:00:00 2008 PDT
isdst=1
PST8PDT Sun Oct 26 08:59:59 2008 UTC = Sun Oct 26 01:59:59 2008 PDT
isdst=1
PST8PDT Sun Oct 26 09:00:00 2008 UTC = Sun Oct 26 01:00:00 2008 PST
isdst=0

In other words, it still appears that the DST changes are happening in
April and October, instead of March and November.

So what am I doing wrong? Maybe I'm trying to zdump the wrong file,
but running zdump on the other ones that seem likely produce output
lines only for 1901 and 2038.

Thanks in advance for any help you can provide.

-- thanks, Adam

"Adam Beneschan" <adam@irvine.com> writes:

>Hi,

>I'm trying to fix things for the upcoming Daylight Savings Time
>change. We're using a rather old Red Hat Linux system. (Please, no
>questions about why we haven't upgraded.)

>A couple of places recommended downloading the timezone files from
>ftp://elsie.nci.nih.gov/pub/ and running zic on the files, but I'm not
>sure it worked right. I don't know if I did something wrong, or if
>I'm wrong to expect different output from what I'm getting...

>I went to that site and downloaded and unpackaged tzcode2007c.tar.gz
>and tzdata2007c.tar.gz. First, in tzcode2007c, I did a "make" to
>rebuild zic and zdump. (It complained about yearistype.sh not being
>found in tzcode2007c, so I symlinked the one I found in tzdata2007c
>and continued.) Then, in tzdata2007c, I tried to run zic on the
>files, using the zic I just built. All the files except three,
>iso3166.tab, zone.tab, and yearistype.sh, looked like source files for
>zic, so I ran it with a command like this:

> zic -d mytestdir [a-f]* [l-s]*


DO you really live everywhere in th eworld?
northamerica is the only one youneed to compile.



>to pick up all the files except for those three. The result was a
>bunch of files and subdirectories being created in mytestdir.

>But then I ran the zdump I just built on the PST8PDT file that zic
>just created:

> zdump -v mytestdir/PST8PDT

>The portion of the output for the years 2006 through 2008 looked like
>this:

>PST8PDT Sun Apr 2 09:59:59 2006 UTC = Sun Apr 2 01:59:59 2006 PST
>isdst=0
>PST8PDT Sun Apr 2 10:00:00 2006 UTC = Sun Apr 2 03:00:00 2006 PDT
>isdst=1
>PST8PDT Sun Oct 29 08:59:59 2006 UTC = Sun Oct 29 01:59:59 2006 PDT
>isdst=1
>PST8PDT Sun Oct 29 09:00:00 2006 UTC = Sun Oct 29 01:00:00 2006 PST
>isdst=0
>PST8PDT Sun Apr 1 09:59:59 2007 UTC = Sun Apr 1 01:59:59 2007 PST
>isdst=0
>PST8PDT Sun Apr 1 10:00:00 2007 UTC = Sun Apr 1 03:00:00 2007 PDT
>isdst=1
>PST8PDT Sun Oct 28 08:59:59 2007 UTC = Sun Oct 28 01:59:59 2007 PDT
>isdst=1
>PST8PDT Sun Oct 28 09:00:00 2007 UTC = Sun Oct 28 01:00:00 2007 PST
>isdst=0
>PST8PDT Sun Apr 6 09:59:59 2008 UTC = Sun Apr 6 01:59:59 2008 PST
>isdst=0
>PST8PDT Sun Apr 6 10:00:00 2008 UTC = Sun Apr 6 03:00:00 2008 PDT
>isdst=1
>PST8PDT Sun Oct 26 08:59:59 2008 UTC = Sun Oct 26 01:59:59 2008 PDT
>isdst=1
>PST8PDT Sun Oct 26 09:00:00 2008 UTC = Sun Oct 26 01:00:00 2008 PST
>isdst=0

>In other words, it still appears that the DST changes are happening in
>April and October, instead of March and November.

I jst did it and got the right rules.
PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST
isdst=0 gmtoff=-28800
PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT
isdst=1 gmtoff=-25200
PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST
isdst=0 gmtoff=-28800

So, I have no idea what you did.
Maybe you have an old northamerica file in your directory. Or one labeled
differently but with those contents.
I would just do
zic -d mytestdir northamerica


>So what am I doing wrong? Maybe I'm trying to zdump the wrong file,
>but running zdump on the other ones that seem likely produce output
>lines only for 1901 and 2038.

>Thanks in advance for any help you can provide.

> -- thanks, Adam

Unruh wrote:
> "Adam Beneschan" <adam@irvine.com> writes:
>
>> Hi,
>
>> I'm trying to fix things for the upcoming Daylight Savings Time
>> change. We're using a rather old Red Hat Linux system. (Please, no
>> questions about why we haven't upgraded.)
>
>> A couple of places recommended downloading the timezone files from
>> ftp://elsie.nci.nih.gov/pub/ and running zic on the files, but I'm not
>> sure it worked right. I don't know if I did something wrong, or if
>> I'm wrong to expect different output from what I'm getting...
>
>> I went to that site and downloaded and unpackaged tzcode2007c.tar.gz
>> and tzdata2007c.tar.gz. First, in tzcode2007c, I did a "make" to
>> rebuild zic and zdump. (It complained about yearistype.sh not being
>> found in tzcode2007c, so I symlinked the one I found in tzdata2007c
>> and continued.) Then, in tzdata2007c, I tried to run zic on the
>> files, using the zic I just built. All the files except three,
>> iso3166.tab, zone.tab, and yearistype.sh, looked like source files for
>> zic, so I ran it with a command like this:
>
>> zic -d mytestdir [a-f]* [l-s]*
>
>
> DO you really live everywhere in th eworld?
> northamerica is the only one youneed to compile.
>
While this is probably true, it is not necessarily so.
If the O.P. runs his machine as a computer server, where people can login
from anywhere in the world either by dial-up (extremely unlikely) or over
the Internet, he would want all the time zones compiled in since each user
might be in a different one.

Remember that the UNIX O.S. was originally designed as a multi-user system
and all the users had dumb terminals. You could certainly use an old Windows
machine as a dumb terminal, though you would probably prefer to have it run
an X server. They used to make X-terminals, but the demand for them is so
low that they cost more than a PC the last time I looked.

It still works, though. I have run programs on this machine (e.g., Firefox)
from another machine on my LAN. It was kind-of funny. My sister was logged
into this machine with her login, and was running Firefox. I was logged into
this machine from my other machine, and I was running Firefox as well. Since
the Internet connection is very fast, we did not even step on one-another's
toes. Neither of use was doing real-time videos, though.

--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 09:15:01 up 13 days, 21:39, 3 users, load average: 4.10, 4.10, 4.13

On Mar 1, 11:38 pm, Unruh <unruh-s...@physics.ubc.ca> wrote:

> DO you really live everywhere in th eworld?

No. I've been putting on weight, but not *that* much.

> northamerica is the only one youneed to compile.

I tried that first. When it didn't work, I thought maybe I needed to
compile all of them, that there was some interaction between the files
that was being missed.



> I jst did it and got the right rules.
> PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST
> isdst=0 gmtoff=-28800
> PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT
> isdst=1 gmtoff=-25200
> PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT
> isdst=1 gmtoff=-25200
> PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST
> isdst=0 gmtoff=-28800
>
> So, I have no idea what you did.
> Maybe you have an old northamerica file in your directory. Or one labeled
> differently but with those contents.

The one I'm using has these two lines:

Rule US 2007 max - Mar Sun>=8 2:00 1:00 D
Rule US 2007 max - Nov Sun>=1 2:00 0 S

and a couple similar lines for Canada, and a reference to the Energy
Policy Act of 2005.

> I would just do
> zic -d mytestdir northamerica

I'll retry it to make absolutely sure that I'm using the right zic and
looking at the right versions of files, but I have this vague sense of
impending major frustration.

zic doesn't depend on any library modules to do any of these
computations, does it? If it did, I'd think that perhaps old library
files on my system would explain why it works for you but not for me.
Otherwise, I can't think of an explanation.

zic --version gives me 8.10, by the way. zdump is 8.3.

Sigh... I'll try again.

-- Adam

On 1 Mar 2007, in the Usenet newsgroup comp.os.linux.setup, in article
<1172774546.090803.143590@j27g2000cwj.googlegroups .com>, Adam Beneschan wrote:

>I'm trying to fix things for the upcoming Daylight Savings Time
>change. We're using a rather old Red Hat Linux system. (Please, no
>questions about why we haven't upgraded.)

libc5 distributions (up to Red Hat 4.2 in 1997) had the zone files in
the 'zoneinfo' package. glibc2 versions of Red Hat (5.0 to 9) moved
the file to the 'glibc-2*' package. Updated packages for Red Hat 7.3
and 9 were made available a _YEAR_ ago, and you may find them on
downloads.fedoralegacy.org. For versions OTHER THAN 7.3 and 9, and
for the earlier libc5 distributions, your best bet is elsie.nci.nih.gov.
Fedora, and Red Hat Enterprise Linux moved the zonefiles to a 'tzdata'
package. Updates were made available for these about a year ago.

>A couple of places recommended downloading the timezone files from
>ftp://elsie.nci.nih.gov/pub/ and running zic on the files, but I'm not
>sure it worked right. I don't know if I did something wrong, or if
>I'm wrong to expect different output from what I'm getting...

Your description doesn't sound as if you followed the instructions in
the README files.

>But then I ran the zdump I just built on the PST8PDT file that zic
>just created:
>
> zdump -v mytestdir/PST8PDT

The preference is to use the named zonefile (America/Los_Angeles),
although the old PST8PDT should also work. However, your output looks
as if it's still using the old files. Try moving/copying your new
zonefiles to /usr/share/zoneinfo. If you are nervous about this, try
moving the 'America/Denver' file only and run zdump against that zone,
comparing the result to running against America/Los_Angeles.

Old guy

On Mar 2, 11:59 am, ibupro...@painkiller.example.tld (Moe Trin) wrote:

> Try moving/copying your new
> zonefiles to /usr/share/zoneinfo. If you are nervous about this, try
> moving the 'America/Denver' file only and run zdump against that zone,
> comparing the result to running against America/Los_Angeles.
>
> Old guy

OK, that gave me the clue I needed...

I just tried again, and I found out that zdump doesn't actually take a
file name, or at least it tries not to. If I give it a complete path
beginning with /, it dumps the file I tell it to. Otherwise, it gets
the file from somewhere else.

If my file is in /users/adam/subdir/testdir, and I cd to subdir, I get
three different results with:

zdump -v testdir/PST8PDT
zdump -v ../subdir/testdir/PST8PDT
zdump -v /users/adam/subdir/testdir/PST8PDT

The first two seem to find some zone file from somewhere, even though
there's no "testdir" in the /usr/share/zoneinfo structure; it somehow
munges the name and comes up with some sort of zone file to dump. And
they come up with different files. The last one is the one I need.

I tried to look at zdump.c, and I don't understand how it works, but
it appears that it isn't trying to open any files itself but rather is
relying on the libraries, which think they're supposed to be reading
files from the standard location unless I fool them (apparently via
the TZ environment variable). This seems like a flaw; I would think
that it would be good practice to run zic first and look at the
resulting files with a dump tool to make sure you've done things right
before you install---rather than to run zic first, install the files,
and then make sure they're correct.

Oh, well. Anyway, it looks like things did work fine. Thanks to
everyone for your help.

-- Adam

"Adam Beneschan" <adam@irvine.com> writes:

>On Mar 1, 11:38 pm, Unruh <unruh-s...@physics.ubc.ca> wrote:

>> DO you really live everywhere in th eworld?

>No. I've been putting on weight, but not *that* much.

>> northamerica is the only one youneed to compile.

>I tried that first. When it didn't work, I thought maybe I needed to
>compile all of them, that there was some interaction between the files
>that was being missed.

Nope. What do you mean "it did not work"?


Do you want me to send you a good pst8pdt or perhaps a Vancouver one?




>> I jst did it and got the right rules.
>> PST8PDT Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST
>> isdst=0 gmtoff=-28800
>> PST8PDT Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT
>> isdst=1 gmtoff=-25200
>> PST8PDT Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT
>> isdst=1 gmtoff=-25200
>> PST8PDT Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST
>> isdst=0 gmtoff=-28800
>>
>> So, I have no idea what you did.
>> Maybe you have an old northamerica file in your directory. Or one labeled
>> differently but with those contents.

>The one I'm using has these two lines:

>Rule US 2007 max - Mar Sun>=8 2:00 1:00 D
>Rule US 2007 max - Nov Sun>=1 2:00 0 S

>and a couple similar lines for Canada, and a reference to the Energy
>Policy Act of 2005.

Sounds good.


>> I would just do
>> zic -d mytestdir northamerica

>I'll retry it to make absolutely sure that I'm using the right zic and
>looking at the right versions of files, but I have this vague sense of
>impending major frustration.

>zic doesn't depend on any library modules to do any of these
>computations, does it? If it did, I'd think that perhaps old library
>files on my system would explain why it works for you but not for me.
>Otherwise, I can't think of an explanation.

>zic --version gives me 8.10, by the way. zdump is 8.3.

Well, mine gives 7.128

Actually look in /usr/share/zoneinfo to see if the files there have
changed?




>Sigh... I'll try again.

> -- Adam

On Mar 2, 4:36 pm, "Adam Beneschan" <a...@irvine.com> wrote:

> Oh, well. Anyway, it looks like things did work fine. Thanks to
> everyone for your help.

OK, everything's working now---thanks again for all your help.

I do have one more question. Assuming I don't reboot our systems any
time between now and next week, what will happen with the cron
daemons? Will they automatically adjust to the new time, or will I
have to stop and restart them or do something else to refresh the time
zone tables used by the Unix library routines, or something like that,
so that it doesn't run everything an hour late? (It's not a disaster
if it runs late, but some backup processes are scheduled so that they
will complete before I come into work, and it will be a minor nuisance
if they're still running.)

-- thanks, Adam

Adam Beneschan wrote:
> On Mar 2, 4:36 pm, "Adam Beneschan" <a...@irvine.com> wrote:
>
>> Oh, well. Anyway, it looks like things did work fine. Thanks to
>> everyone for your help.
>
> OK, everything's working now---thanks again for all your help.
>
> I do have one more question. Assuming I don't reboot our systems any
> time between now and next week, what will happen with the cron
> daemons? Will they automatically adjust to the new time, or will I
> have to stop and restart them or do something else to refresh the time
> zone tables used by the Unix library routines, or something like that,
> so that it doesn't run everything an hour late? (It's not a disaster
> if it runs late, but some backup processes are scheduled so that they
> will complete before I come into work, and it will be a minor nuisance
> if they're still running.)
>
> -- thanks, Adam
>
Everything will be fine unless you try to start things around 2AM on
Sundays. In that case, they will be skipped this week, and run twice next
fall. I solve that by doing this in my /etc/crontab:

# Do not start things from 01:00 to 02:59 because they will run twice
# when the fall switch from daylight savings time to standard time occurs,
# and may be skipped in the spring when 2:00 AM is skipped.

#M H D m d user program arguments
01 * * * * root run-parts /etc/cron.hourly
04 1 * * 1-6 root run-parts /etc/cron.daily
04 3 * * 0 root run-parts /etc/cron.weekly
19 4 1 * * root run-parts /etc/cron.monthly


--
.~. Jean-David Beyer Registered Linux User 85642.
/V\ PGP-Key: 9A2FC99A Registered Machine 241939.
/( )\ Shrewsbury, New Jersey http://counter.li.org
^^-^^ 21:30:01 up 19 days, 9:54, 3 users, load average: 4.25, 4.28, 4.20

Jean-David Beyer writes:
> [Cron] will be fine unless you try to start things around 2AM on
> Sundays. In that case, they will be skipped this week, and run twice next
> fall.

From the cron man page (Vixie cron):

Special considerations exist when the clock is changed by less than
3 hours, for example at the beginning and end of daylight savings
time. If the time has moved forwards, those jobs which would have
run in the time that was skipped will be run soon after the change.
Conversely, if the time has moved backwards by less than 3 hours,
those jobs that fall into the repeated time will not be re-run.

Only jobs that run at a particular time (not specified as @hourly,
nor with '*' in the hour or minute specifier) are affected. Jobs
which are specified with wildcards are run based on the new time
immediately.
--
John Hasler
john@dhh.gt.org
Dancing Horse Hill
Elmwood, WI USA