Tcl Source Code

Hi,
I have compiled tcl8.4.3 on Tru64Unix (formerly OSF1)
and make test fails in many cases. Would someone
inspect the output? Thanks!

I used cc/cxx from vendor, latest version, C*FLAGS"-O2
-arch ev56" if that matters.


The original bugreport is at
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=748804&group_id=10894

==== clock-3.2 clock format tests FAILED
==== Contents of test case:

    # TCL_USE_TIMEZONE_VAR

    catch {set oldtz $env(TZ)}
    set env(TZ) PST
    set x {}
    append x [clock format 863800000 -format %Z -gmt 1]
    append x [set env(TZ)]
    catch {unset env(TZ); set env(TZ) $oldtz}
    set x

---- Result was:
METPST
---- Result should have been (exact matching):
GMTPST
==== clock-3.2 FAILED


==== clock-3.4 clock format tests FAILED
==== Contents of test case:

    # tzset() under Borland doesn't seem to set up
tzname[] for gmt timezone.
    # tzset() under MSVC has the following weird
observed behavior:
    # First time we call "clock format [clock seconds]
-format %Z -gmt 1"
    # we get "GMT", but on all subsequent calls we get
the current time 
    # zone string, even though env(TZ) is GMT and the
variable _timezone 
    #    is 0.

    set x {}
    append x [clock format 863800000 -format %Z -gmt 1]
    append x [clock format 863800000 -format %Z -gmt 1]

---- Result was:
METMET
---- Result should have been (exact matching):
GMTGMT
==== clock-3.4 FAILED

Logged In: YES 
user_id=99768

Fixed in 8.5

Logged In: YES 
user_id=99768

It appears that Tru64 Unix needs to use compat/strftime.c -
alas, this will break l10n.  Reopening the bug.

File Added - 87616: log

Logged In: YES 
user_id=696559

OK, I tested agains tcl cvs HEAD, see attachment.

Logged In: YES 
user_id=696559

Tested against latest snapshot tcl-20040506.tar.gz on
another host running same OS:

clock.test

==== clock-3.2 clock format tests FAILED
==== Contents of test case:

    # TCL_USE_TIMEZONE_VAR

    catch {set oldtz $env(TZ)}
    set env(TZ) PST
    set x {}
    append x [clock format 863800000 -format %Z -gmt 1]
    append x [set env(TZ)]
    catch {unset env(TZ); set env(TZ) $oldtz}
    set x

---- Result was:
CETPST
---- Result should have been (exact matching):
GMTPST
==== clock-3.2 FAILED


==== clock-3.4 clock format tests FAILED
==== Contents of test case:

    # tzset() under Borland doesn't seem to set up tzname[]
for gmt timezone.
    # tzset() under MSVC has the following weird observed
behavior:
    #    First time we call "clock format [clock seconds]
-format %Z -gmt 1"
    #    we get "GMT", but on all subsequent calls we get
the current time 
    #    zone string, even though env(TZ) is GMT and the
variable _timezone 
    #    is 0.

    set x {}
    append x [clock format 863800000 -format %Z -gmt 1]
    append x [clock format 863800000 -format %Z -gmt 1]

---- Result was:
CETCET
---- Result should have been (exact matching):
GMTGMT
==== clock-3.4 FAILED

Logged In: YES 
user_id=99768

Can this be retested either against the current HEAD or
against the tip of  core-8-4-branch?  I've not got a Tru64
system to test against, but I suspect that some recent
changes to tclUnixTime.c have fixed this bug.

Logged In: YES 
user_id=99768

This appears to be a peculiarity in the platform's native
strftime(); there is a rewrite of [clock format] in development
that avoids the use of this function altogether
(I'm tired of debugging it on various platforms)