TCL and DST..

[Dennis Pfeifer]

Just curious what others are getting…

I did this on a couple of machines ..

tcl>info tclversion

8.3

tcl>clock format 1173599999

Sun Mar 11 01:59:59 CST 2007

tcl>clock format 1173600000

Sun Mar 11 02:00:00 CST 2007

tcl>clock format 1173600001

Sun Mar 11 02:00:01 CST 2007

---

% info tclversion

8.4

% clock format 1173599999

Sun Mar 11 1:59:59 AM Central Standard Time 2007

% clock format 1173600000

Sun Mar 11 3:00:00 AM Central Daylight Time 2007

% clock format 1173600001

Sun Mar 11 3:00:01 AM Central Daylight Time 2007

Topic

[Charlie Bursell]

Dennis:

On my Windoze box I get the same with each version of Tcl

I get a format like: Sun Mar 11 03:00:00 Central Daylight Time 2007

Maybe it is a Linux thing?

[Russ Ross]

We think we have upgraded our AIX box for DST and I get what I would expect when I use hcitcl to run your commands to test DST in TCL.

This leads me to wonder if you need to patch your OS for DST.

Here is what I get

(mdahub10:hci) /quovadx/qdx5.2/integrator/server/logs > hcitcl

hcitcl>info tclversion

8.3

hcitcl>clock format 1173599999

Sun Mar 11 01:59:59 CST 2007

hcitcl>clock format 1173600000

Sun Mar 11 03:00:00 CDT 2007

hcitcl>clock format 1173600001

Sun Mar 11 03:00:01 CDT 2007

hcitcl>

In our case we are running Cloverleaf 5.2.1P2 on AIX 5.2 and here is what we upgraded to in preparation for DST:

(mdahub6:hci) /quovadx/qdx5.2/integrator/server/logs > oslevel -s

5200-09-03

(mdahub6:hci) /quovadx/qdx5.2/integrator/server/logs > lslpp -l |grep Java

 Java131.rte.bin           1.3.1.18  APPLIED    Java Runtime Environment

 Java131.rte.lib           1.3.1.18  APPLIED    Java Runtime Environment

 Java14.sdk                1.4.2.75  APPLIED    Java SDK 32-bit

 Java14_64.debug            1.4.1.3  COMMITTED  Java SDK 64-bit Debug

 Java14_64.ext.commapi      1.4.1.1  COMMITTED  Java SDK 64-bit Comm API

 Java14_64.ext.javahelp     1.4.1.1  COMMITTED  Java SDK 64-bit JavaHelp

 Java14_64.license          1.4.1.0  COMMITTED  Java SDK 64-bit License

 Java14_64.samples          1.4.1.1  COMMITTED  Java SDK 64-bit Samples

 Java14_64.sdk              1.4.1.3  COMMITTED  Java SDK 64-bit

 Java14_64.source           1.4.1.3  COMMITTED  Java SDK 64-bit Source

 idebug.rte.hpj             9.2.5.0  COMMITTED  High-Performance Java Runtime

 idebug.rte.jre             9.2.5.0  COMMITTED  Java Runtime Environment

 idebug.rte.olt.Java        9.2.5.0  COMMITTED  Object Level Trace Java

                                                Java GUI

                           5.2.0.40  COMMITTED  LUM Java GUI Messages – U.S.

 Java14.sdk                1.4.2.75  APPLIED    Java SDK 32-bit

(mdahub6:hci) /quovadx/qdx5.2/integrator/server/logs > lslpp -l |grep JAVA

                            2.3.0.0  COMMITTED  RSCT GUI JAVA Msgs – U.S.

                            2.3.0.0  COMMITTED  RSCT RMC JAVA Msgs – U.S.

I suspect the Java filesets to be most concerned about above are:

Java 131.rte.bin ( we went from 1.3.1.17 to 1.3.1.18 )

Java131.rte.lib ( we went from 1.3.1.17 to 1.3.1.18 )

Java14.sdk ( we went from 1.4.2.3 to 1.4.2.75 )

Russ Ross
RussRoss318@gmail.com

[Dennis Pfeifer]

Thanks for the feedback.

Despite what I’ve been told by our OS group .. I’ve got a feeling that the DST patches for the OS have not been ‘fully’ applied.

I also tested on our RH E4, with CL 5.5 and it returned the correct values….

My previous post with the ‘%’ prompt was on Windows ..

tcl> was on our RH E3, CL 5.3 box …

Dennis

[Charlie Bursell]

For those of you that might be concerned with the impact of DST on Tcl here are a couple of places that discuss the issue:

http://wiki.tcl.tk/14617

http://support.activestate.com/forum-topic/2007-daylight-savings-tim-0

The bottom line is, as long as the OS is properly updated, no problem with Tcl

[Dennis Pfeifer]

Again .. just following up ..

The problem that I am experiencing is related to the system not TCL .. .

perl -e ‘print localtime(1173600000).”n”‘

Sun Mar 11 02:00:00 2007

so .. I’ve got an email out to my sys admin ..

Dennis

[Scott Lee]

It’s not a general Linux thing…

Code:

hcitcl>info tclversion
8.4
hcitcl>clock format 1173596399
Sun Mar 11 01:59:59 AM EST 2007
hcitcl>clock format 1173596400
Sun Mar 11 03:00:00 AM EDT 2007
hcitcl>

Scott

[Dennis Pfeifer]

Thank you Scott …

Last update on the topic ..

The patch was applied, but the /etc/localtime was not updated.. (as specified in the RH instructions)…

From my sys admin…

“After running (and accepting) redhat-config-date (there is no system-config-date on this system) …. your test runs clean now…..thank you for identifying the appropriate procedure from Redhat–I’d missed that.”

Dennis

[Author]

Replies