[ tcl-Bugs-1995175 ] clock scan problems on windows

[SourceForge.net]

Bugs item #1995175, was opened at 2008-06-16 16:04
Message generated for change (Comment added) made by cnassau
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1995175&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 06. Time Measurement
Group: current: 8.5.2
>Status: Closed
>Resolution: None
Priority: 5
Private: No
Submitted By: Christian Nassau (cnassau)
Assigned to: Kevin B KENNY (kennykb)
Summary: clock scan problems on windows

Initial Comment:
clock scan seems to have an issue with dates before 02 Jan 1970 on Windows XP:

  % clock scan "02 Jan 1970"
  82800
  % clock scan "01 Jan 1970"
  time value too large/small to represent

Setting an explicit timezone avoids the problem (i.e. [clock scan "01 Jan 1970" -timezone :GMT] works).

Google knows about a lot of "mktime fails with negative values" complains which might be related.

Also, while investigating this issue, I tried

   tcl::clock::ConvertLocalToUTC {stuff that's not important} {} 12345

This gives a segfault (both on Windows and Solaris)



----------------------------------------------------------------------

>Comment By: Christian Nassau (cnassau)
Date: 2008-06-17 07:52

Message:
Logged In: YES
user_id=902560
Originator: YES

Ah, indeed: we forgot to copy the dde and registry packages when we
bundled Tcl on Windows... once they are installed, everything works fine
again.

Sorry for all the fuss. Thanks for the timely response!

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2008-06-17 04:36

Message:
Logged In: YES
user_id=99768
Originator: NO

Oh... The registry package doesn't load
without help when testing Tcl in the
build directory.  Are you perhaps testing
against an uninstalled Tcl?  If
so, try doing
    load $build_directory/tclreg12.dll Registry
prior to doing anything with [clock].  If the
registry package can't be loaded, what
you describe will be the symptom.

[make test] and [make runtest] get around this
by using
    ::tcltest::loadTestedCommands
    load $::reglib Registry
to force the registry package into the interpreter
before attempting to touch [clock].

If I don't hear otherwise, I'll presume that's
what happened and let the system close the bug.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2008-06-17 04:24

Message:
Logged In: YES
user_id=99768
Originator: NO

The segfault is fixed, but has nothing to do with the main reported bug.
 Ah... I now have a WinXP system that reproduces the bug.  Will
investigate
further.

----------------------------------------------------------------------

Comment By: Kevin B KENNY (kennykb)
Date: 2008-06-17 03:13

Message:
Logged In: YES
user_id=99768
Originator: NO

Hmm. The issue on Windows XP is puzzling.
Are you running a stock Tcl installation?
The symptom is consistent with the default
timezone being set to :localtime, but that
shouldn't happen on Windows.  Tcl gets the
system time zone from the Registry, uses
a tzdata file corresponding to the zone
if it has one, and generates a Posix-style
time zone string if it does not.

Is it possible that you removed the
$tcl_library/tzdata directory (or the file
for the zone in question) from your installation?

In order to troubleshoot this further, let's
find out the following:

(1) What's the result of ::tcl::clock::GuessWindowsTimeZone ?

(If that's :localtime, we need to troubleshoot what's wrong
with the registry.  But I'm guessing that it will have returned
some actual time zone name.)

(2) If it returns a correct time zone name, what is it?
Does the file $tcl_library/tzdata/$timezone (where $timezone
is the returned timezone) exist?  Does the directory
exist at all?

If the file doesn't exist, you can no doubt get around
this problem by fixing your installation. But still,
even if *that* messes up, too, we're still supposed
to recover and give a Posix time zone.  So something
is seriously deranged here.  Maybe the answers to the
questions so far will give more of a hint where to look.

The segfault is a separate issue. Since ConvertLocalToUTC
is private, I haven't thoroughly tested what it does
with bad args. Obviously, you've found a combination
that crashes it.  I'll fix that bit while I'm waiting
for further information.

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1995175&group_id=10894

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Tcl-Bugs mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/tcl-bugs