TCL and DST..

This topic has 7 replies, 4 voices, and was last updated 17 years, 10 months ago by Dennis Pfeifer.

Creator

Topic
February 21, 2007 at 7:30 pm #49095
Dennis Pfeifer
Participant
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
Creator

Topic

Viewing 6 reply threads

Author

Replies
- February 21, 2007 at 9:43 pm #60708
  Charlie Bursell
  Participant
  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?
- February 22, 2007 at 12:01 am #60709
  Russ Ross
  Participant
  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
- February 22, 2007 at 12:49 am #60710
  Dennis Pfeifer
  Participant
  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
- February 22, 2007 at 1:32 pm #60711
  Charlie Bursell
  Participant
  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
- February 22, 2007 at 1:47 pm #60712
  Dennis Pfeifer
  Participant
  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
- February 22, 2007 at 2:14 pm #60713
  Scott Lee
  Participant
  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
- February 22, 2007 at 2:44 pm #60714
  Dennis Pfeifer
  Participant
  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

Viewing 6 reply threads

The forum ‘General’ is closed to new topics and replies.