Solaris 2.7 Daylight saving time fix.

[Larry Cashdollar]

Hi,
   I am working on getting Solaris 2.7 compliant with the new DST changes for March 2007.  I downloaded the latest updates from:

wget ftp://elsie.nci.nih.gov/pub/tz*.tar.gz

Ran zic on northamerica
Then tested with a zdump:


zdump -v EST5EDT |grep 2007


which still reported April when the DST would occur.  What am I missing? this worked for linux.

[Blaine Lefler]

Because Sol 7 is EOL there is no DST patch. You need to either upgrade,
adjust the date by hand or put the system on GMT.

Blaine Lefler
who has 50 more DST patches to install

lcashdol@... wrote:

> Hi,
>    I am working on getting Solaris 2.7 compliant with the new DST changes for March 2007.  I downloaded the latest updates from:
>
> wget ftp://elsie.nci.nih.gov/pub/tz*.tar.gz
>
> Ran zic on northamerica
> Then tested with a zdump:
>
>
> zdump -v EST5EDT |grep 2007
>
>
> which still reported April when the DST would occur.  What am I missing? this worked for linux.
>
>
>

--
Blaine Lefler
Lefler Enterprises
Phone: [phone]
Email: blaine@...
Web: www.leflerenterprises.com

[Blaine Lefler]

Forgot to add this,
DST Patches

SPARC Platform

     * Solaris 8 without patches 109809-02 and 108993-52
     * Solaris 9 without patches 113225-03 and 112874-33
     * Solaris 10 without patches 122032-01 and 119689-07

x86 Platform

     * Solaris 8 without patches 109810-02 and 108994-52
     * Solaris 9 without patches 116545-02 and 114432-23
     * Solaris 10 without patches 122033-01 and 121208-03


lcashdol@... wrote:

> Hi,
>    I am working on getting Solaris 2.7 compliant with the new DST changes for March 2007.  I downloaded the latest updates from:
>
> wget ftp://elsie.nci.nih.gov/pub/tz*.tar.gz
>
> Ran zic on northamerica
> Then tested with a zdump:
>
>
> zdump -v EST5EDT |grep 2007
>
>
> which still reported April when the DST would occur.  What am I missing? this worked for linux.
>
>
>

--
Blaine Lefler
Lefler Enterprises
Phone: [phone]
Email: blaine@...
Web: www.leflerenterprises.com

[Andy_Bach]

>  zdump -v EST5EDT |grep 2007
> which still reported April when the DST would occur.  What am I missing?
this worked for linux.

I built the tools that come in the code bundle and:
#  code/zdump -v CST6CDT | grep 2007
CST6CDT  Sun Mar 11 07:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 CST
isdst=0
CST6CDT  Sun Mar 11 08:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 CDT
isdst=1
CST6CDT  Sun Nov  4 06:59:59 2007 UTC = Sun Nov  4 01:59:59 2007 CDT
isdst=1
CST6CDT  Sun Nov  4 07:00:00 2007 UTC = Sun Nov  4 01:00:00 2007 CST
isdst=0

#  zdump -v CST6CDT | grep 2007
CST6CDT  Wed Jan 10 23:23:36 2007 GMT = Wed Jan 10 17:23:36 2007 CST
isdst=0
CST6CDT  Sun Apr  1 07:59:59 2007 GMT = Sun Apr  1 01:59:59 2007 CST
isdst=0
CST6CDT  Sun Apr  1 08:00:00 2007 GMT = Sun Apr  1 03:00:00 2007 CDT
isdst=1
CST6CDT  Sun Oct 28 06:59:59 2007 GMT = Sun Oct 28 01:59:59 2007 CDT
isdst=1
CST6CDT  Sun Oct 28 07:00:00 2007 GMT = Sun Oct 28 01:00:00 2007 CST
isdst=0

They work, where Sun's doesn't, though for, say Chicago:
 #  zdump -v America/Chicago | grep 2007
America/Chicago  Wed Jan 10 23:25:11 2007 GMT = Wed Jan 10 17:25:11 2007
CST isdst=0
America/Chicago  Sun Mar 11 07:59:59 2007 GMT = Sun Mar 11 01:59:59 2007
CST isdst=0
America/Chicago  Sun Mar 11 08:00:00 2007 GMT = Sun Mar 11 03:00:00 2007
CDT isdst=1
America/Chicago  Sun Nov  4 06:59:59 2007 GMT = Sun Nov  4 01:59:59 2007
CDT isdst=1
America/Chicago  Sun Nov  4 07:00:00 2007 GMT = Sun Nov  4 01:00:00 2007
CST isdst=0

it does. So I did a truss on zdump for CST6CDT and it never opens a
zoneinfo file. It just calls "time()". But it does open the zoneinfo file
for America/Chicago.
http://sunsolve.sun.com/search/document.do?assetkey=1-26-102178-1

appears to be some patches for it.

a

Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

If  it's not  on  fire  it's  a  software  problem.

[Keith Farrar]

You can clone the relevant parts of a working patch for Solaris 8
with a short shell script (worked fine on Solaris 2.6 and Solaris 7).

        -KF

#!/bin/sh
## shell script hack to force solaris DST zonefile updates
##  - use cat to preserve hard links between zonefiles
##  - only update pre-existing files
## unpack Solaris 8 DST patch 109809-04 under /var/tmp/
## then run this script on Solaris 2.6 / 7 systems
## Keith Farrar <kfarrar@...>

cd /var/tmp/109809-04/SUNWcsu/reloc/usr/share/lib/zoneinfo

# for f in `find Mideast -type f -print`
for f in `find * -type f -print`
do if [ -f  /usr/share/lib/zoneinfo/$f ]; then
                cat $f > /usr/share/lib/zoneinfo/$f
                ls -lg /usr/share/lib/zoneinfo/$f
        fi
done




lcashdol@... wrote:

> Hi,
>    I am working on getting Solaris 2.7 compliant with the new DST changes for March 2007.  I downloaded the latest updates from:
>
> wget ftp://elsie.nci.nih.gov/pub/tz*.tar.gz
>
> Ran zic on northamerica
> Then tested with a zdump:
>
>
> zdump -v EST5EDT |grep 2007
>
>
> which still reported April when the DST would occur.  What am I missing? this worked for linux.

[Riddle, Bruce (Bruce) %]

Keith,

After doing such on a 2.7 or 2.6 machine what does "zdump -v EST5EDT  |
grep 2007"
Report?

Bruce

-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of Keith Farrar
Sent: Monday, January 15, 2007 2:53 PM
To: lcashdol@...
Cc: focus-sun@...
Subject: Re: Solaris 2.7 Daylight saving time fix.

You can clone the relevant parts of a working patch for Solaris 8 with a
short shell script (worked fine on Solaris 2.6 and Solaris 7).

        -KF

#!/bin/sh
## shell script hack to force solaris DST zonefile updates ##  - use cat
to preserve hard links between zonefiles ##  - only update pre-existing
files ## unpack Solaris 8 DST patch 109809-04 under /var/tmp/ ## then
run this script on Solaris 2.6 / 7 systems ## Keith Farrar
<kfarrar@...>

cd /var/tmp/109809-04/SUNWcsu/reloc/usr/share/lib/zoneinfo

# for f in `find Mideast -type f -print` for f in `find * -type f
-print`
do if [ -f  /usr/share/lib/zoneinfo/$f ]; then
                cat $f > /usr/share/lib/zoneinfo/$f
                ls -lg /usr/share/lib/zoneinfo/$f
        fi
done




lcashdol@... wrote:
> Hi,
>    I am working on getting Solaris 2.7 compliant with the new DST
changes for March 2007.  I downloaded the latest updates from:

>
> wget ftp://elsie.nci.nih.gov/pub/tz*.tar.gz
>
> Ran zic on northamerica
> Then tested with a zdump:
>
>
> zdump -v EST5EDT |grep 2007
>
>
> which still reported April when the DST would occur.  What am I

missing? this worked for linux.

[Andy_Bach]

> You can clone the relevant parts of a working patch for Solaris 8
with a short shell script (worked fine on Solaris 2.6 and Solaris 7).

No luck, least-wise not w/ the 'old' CST6CDT formated TZ-style. Even using
the 2.8 updated zdump/zic.  It appears (from truss) that using these
formats ignores the zoneinfo files. The CST6CDT zoneinfo file does contain
the correct DST date (I copied one to a new TZ name and tested that w/ the
zdumps).  The zdump.c code for sol I can find:
http://cvs.opensolaris.org/source/xref/loficc/crypto/usr/src/cmd/zdump/zdump.c

appears to be a port of the NIH code which dutifully opens the appropriate
zoneinfo file. I can compile that and it works - even if I use the sol
zoneinfo files. Hmm, is this only a zdump (pre 10 (at least) anyway)
problem? That  is, after changing my TIMEZONE to use US/Central is there
another test to see if solaris will have an issue?

a

Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

If  it's not  on  fire  it's  a  software  problem.

[Casper.Dik]

>No luck, least-wise not w/ the 'old' CST6CDT formated TZ-style. Even using
>the 2.8 updated zdump/zic.  It appears (from truss) that using these
>formats ignores the zoneinfo files. The CST6CDT zoneinfo file does contain
>the correct DST date (I copied one to a new TZ name and tested that w/ the
>zdumps).  The zdump.c code for sol I can find:
>http://cvs.opensolaris.org/source/xref/loficc/crypto/usr/src/cmd/zdump/zdump.c

Yes, POSIX requires that it ignores the zoneinfo files.

>appears to be a port of the NIH code which dutifully opens the appropriate
>zoneinfo file. I can compile that and it works - even if I use the sol
>zoneinfo files. Hmm, is this only a zdump (pre 10 (at least) anyway)
>problem? That  is, after changing my TIMEZONE to use US/Central is there
>another test to see if solaris will have an issue?


Why can't you just install the zoneinfo files and set the TZ to
America/Whatever?

Casper

[Levenglick, Jeff]

-----Original Message-----
From: Levenglick, Jeff
Sent: Thursday, January 18, 2007 9:04 AM
To: Casper.Dik@...; Andy_Bach@...
Cc: Keith Farrar; focus-sun@...; lcashdol@...;
listbounce@...
Subject: RE: Solaris 2.7 Daylight saving time fix.

Try this link:

http://java.sun.com/javase/tzupdater_README.html

Ibm's tool:

http://www-128.ibm.com/developerworks/java/jdk/dst/index.html

hp's tool:

http://www.hp.com/products1/unix/java/DST-US.html

Jeff


-----Original Message-----
From: listbounce@... [mailto:listbounce@...]
On Behalf Of Casper.Dik@...
Sent: Wednesday, January 17, 2007 2:04 PM
To: Andy_Bach@...
Cc: Keith Farrar; focus-sun@...; lcashdol@...;
listbounce@...
Subject: Re: Solaris 2.7 Daylight saving time fix.


>No luck, least-wise not w/ the 'old' CST6CDT formated TZ-style. Even
using
>the 2.8 updated zdump/zic.  It appears (from truss) that using these
>formats ignores the zoneinfo files. The CST6CDT zoneinfo file does
contain
>the correct DST date (I copied one to a new TZ name and tested that w/
the
>zdumps).  The zdump.c code for sol I can find:
>http://cvs.opensolaris.org/source/xref/loficc/crypto/usr/src/cmd/zdump/
zdump.c

Yes, POSIX requires that it ignores the zoneinfo files.

>appears to be a port of the NIH code which dutifully opens the
appropriate
>zoneinfo file. I can compile that and it works - even if I use the sol
>zoneinfo files. Hmm, is this only a zdump (pre 10 (at least) anyway)
>problem? That  is, after changing my TIMEZONE to use US/Central is
there
>another test to see if solaris will have an issue?


Why can't you just install the zoneinfo files and set the TZ to
America/Whatever?

Casper


-----------------------------------------
This e-mail message is private and may contain confidential or
privileged information.

[daniel.raymer]

Sadly, this script still leaves me with zdump -v showing April 1st for DST changeover.

[Andy_Bach]

> Sadly, this script still leaves me with zdump -v showing April 1st for
DST changeover.

Yeah, it appears you need to do a couple things - one is change from the
old school "?STx?DT"  TZ format (to US/Central for example) and the other
is to ditch the solaris zdump for the nih one.  I'm still hoping for a
response but it was indicated that Sun holds that the ?STx?DT format
precludes using any zoneinfo files - not sure where it gets the info then
(one of libc or libdl? time()?) but ....

Not sure if the "problem" extends beyond just zdump, that is, what other
programs might not use the zoneinfo info

a


Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

   Although few may originate a policy, we are all able to judge it.
    Pericles of Athens, c.430 B.C.

[Raymer, Daniel L.]

I did a work around...

The problem was zic and zdump were not being pulled from the patch by
the script.  I extracted the binaries and put them in /usr/sbin then
just took the src files from the patch and placed them in
/usr/share/lib/zoneinfo/src.  After a quick zic northamerica and reboot,
DST was reporting properly.

If you do not pull zic and zdump from the patch, they will continue to
report the incorrect data as the old zic will not compile the new
timezones correctly.

Daniel Raymer
Unix Systems Administrator
ITS
Vanderbilt University

-----Original Message-----
From: Andy_Bach@... [mailto:Andy_Bach@...]
Sent: Friday, January 26, 2007 1:43 PM
To: Raymer, Daniel L.
Cc: focus-sun@...; listbounce@...
Subject: Re: Re: Solaris 2.7 Daylight saving time fix.

> Sadly, this script still leaves me with zdump -v showing April 1st for

DST changeover.

Yeah, it appears you need to do a couple things - one is change from the

old school "?STx?DT"  TZ format (to US/Central for example) and the
other
is to ditch the solaris zdump for the nih one.  I'm still hoping for a
response but it was indicated that Sun holds that the ?STx?DT format
precludes using any zoneinfo files - not sure where it gets the info
then
(one of libc or libdl? time()?) but ....

Not sure if the "problem" extends beyond just zdump, that is, what other

programs might not use the zoneinfo info

a


Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

   Although few may originate a policy, we are all able to judge it.
    Pericles of Athens, c.430 B.C.

[rjack22us]

This seems to work for us for US/Eastern (note - no changes to existing
zdump/zic):

1) copy /usr/share/lib/zoneinfo/northamerica to
/usr/share/lib/zoneinfo/northamerica.sav for safety/fallback.

2) unpack solaris 8 patch 109809-04. copy
/<rootdirpath>/109809-04/SUNWcsu/reloc/usr/share/lib/zoneinfo/src/northamerica
to /usr/share/lib/zoneinfo/northamerica. this new source file contains the
2007 DST date rule lines:

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

3) edit /usr/share/lib/zoneinfo/northamerica.

Zone    EST5EDT          -5:00  US      E%sT <-- yank this line. paste
below.
Zone    Eastern          -5:00  US      E%sT <-- change to "Eastern"

4) recompile zoneinfo file(s).
#
# zic northamerica

   /usr/share/lib/zoneinfo/Eastern is created as a result.

5) copy /usr/share/lib/zoneinfo/US/Eastern to
/usr/share/lib/zoneinfo/US/Eastern.sav for safety/fallback.

6) copy /usr/share/lib/zoneinfo/Eastern to
/usr/share/lib/zoneinfo/US/Eastern.

7) verify timezone.
#
# echo $TZ
US/Eastern

8) verify system is referencing new DST dates.
#
# zdump -v US/Eastern | grep 2007
US/Eastern  Fri Jan 26 16:39:07 2007 GMT = Fri Jan 26 11:39:07 2007 EST
isdst=0
US/Eastern  Sun Mar 11 06:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 EST
isdst=0
US/Eastern  Sun Mar 11 07:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 EDT
isdst=1
US/Eastern  Sun Nov  4 05:59:59 2007 GMT = Sun Nov  4 01:59:59 2007 EDT
isdst=1
US/Eastern  Sun Nov  4 06:00:00 2007 GMT = Sun Nov  4 01:00:00 2007 EST
isdst=0

9) test time changes by setting appropriate GMT values (-u date option).
the november time change was not observable by us when setting the date
without -u.
#
# date -u 031106592007.50 (a GMT of local time + 5 hours = EST)
Sun Mar 11 06:59:50 GMT 2007
# date
Sun Mar 11 01:59:52 EST 2007
# date
Sun Mar 11 03:00:00 EDT 2007
#
# date -u 110405592007.50 (a GMT of local time + 4 hours = EDT)
Sun Nov  4 05:59:50 GMT 2007
# date
Sun Nov  4 01:59:53 EDT 2007
# date
Sun Nov  4 01:00:13 EST 2007

[Casper.Dik]

>old school "?STx?DT"  TZ format (to US/Central for example) and the other
>is to ditch the solaris zdump for the nih one.  I'm still hoping for a
>response but it was indicated that Sun holds that the ?STx?DT format
>precludes using any zoneinfo files - not sure where it gets the info then
>(one of libc or libdl? time()?) but ....

The POSIX standard *requires* that the ?STx?DT format precludes
the use of zone files.

Any OS which uses the zoneinfo files is not compliant when the $TZ
variable can be parsed under the POSIX rules.

Casper

[Andy_Bach]

> The POSIX standard *requires* that the ?STx?DT format precludes
the use of zone files.

> Any OS which uses the zoneinfo files is not compliant when the $TZ
variable can be parsed under the POSIX rules.

Okay, well the NIH zdump (and, as it happens, the Sol 10 zdump.c I got to
compile on Sol 2.7), "trussed" shows:
open("/usr/share/lib/zoneinfo/GMT", O_RDONLY)   = 3
open("/usr/share/lib/zoneinfo/CST6CDT", O_RDONLY) = 3

So I guess the reason it 'works' is its not properly POSIX ... so the
question (to my mind) remains - where does Sol's POSIX-valid zdump get its
TZ info?  From a library file?  That would be the one we need to update.

a

Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

   Although few may originate a policy, we are all able to judge it.
    Pericles of Athens, c.430 B.C.

[Casper.Dik]

>> The POSIX standard *requires* that the ?STx?DT format precludes
>the use of zone files.
>
>> Any OS which uses the zoneinfo files is not compliant when the $TZ
>variable can be parsed under the POSIX rules.
>
>Okay, well the NIH zdump (and, as it happens, the Sol 10 zdump.c I got to
>compile on Sol 2.7), "trussed" shows:
>open("/usr/share/lib/zoneinfo/GMT", O_RDONLY)   = 3
>open("/usr/share/lib/zoneinfo/CST6CDT", O_RDONLY) = 3
>
>So I guess the reason it 'works' is its not properly POSIX ... so the
>question (to my mind) remains - where does Sol's POSIX-valid zdump get its
>TZ info?  From a library file?  That would be the one we need to update.

If Solaris zdump does not dump the zone file, then that's somewhat
strange; these POSIX rules are hardcoded in the library
file.

What you really should do is switch to the appriate Olson timezone.

(US/...)

Casper

[Cleverson de Freitas Ferla]

-----Mensagem original-----
De: listbounce@... [mailto:listbounce@...] Em
nome de Andy_Bach@...
Enviada em: sexta-feira, 26 de janeiro de 2007 16:43
Para: daniel.raymer@...
Cc: focus-sun@...; listbounce@...
Assunto: Re: Re: Solaris 2.7 Daylight saving time fix.

> Sadly, this script still leaves me with zdump -v showing April 1st for
DST changeover.

Yeah, it appears you need to do a couple things - one is change from the
old school "?STx?DT"  TZ format (to US/Central for example) and the other
is to ditch the solaris zdump for the nih one.  I'm still hoping for a
response but it was indicated that Sun holds that the ?STx?DT format
precludes using any zoneinfo files - not sure where it gets the info then
(one of libc or libdl? time()?) but ....

Not sure if the "problem" extends beyond just zdump, that is, what other
programs might not use the zoneinfo info

a


Andy Bach
Systems Mangler
Internet: andy_bach@...
VOICE: [phone]  FAX [phone]

   Although few may originate a policy, we are all able to judge it.
    Pericles of Athens, c.430 B.C.

[Keith Farrar]

daniel.raymer@... wrote:
> Sadly, this script still leaves me with zdump -v showing April 1st for DST changeover.


The cheesy file copy update appears to work for non-POSIX time zones.

%  zdump -v US/Pacific | egrep 2007
US/Pacific  Tue Jan 30 01:20:52 2007 GMT = Mon Jan 29 17:20:52 2007 PST isdst=0
US/Pacific  Sun Mar 11 09:59:59 2007 GMT = Sun Mar 11 01:59:59 2007 PST isdst=0
US/Pacific  Sun Mar 11 10:00:00 2007 GMT = Sun Mar 11 03:00:00 2007 PDT isdst=1
US/Pacific  Sun Nov  4 08:59:59 2007 GMT = Sun Nov  4 01:59:59 2007 PDT isdst=1
US/Pacific  Sun Nov  4 09:00:00 2007 GMT = Sun Nov  4 01:00:00 2007 PST isdst=0

% date -u
Tue Jan 30 01:21:11 GMT 2007

[Riddle, Bruce (Bruce) %]

Terix seems to be handing out a patch