clock scan 8.4/8.5 incompatibility?
Adrian Davis
generates an error - whereas, 8.4 succeeds and returns a "negative"
result.
Is this a bug?
Regards,
=Adrian=
Kevin Kenny
Yes. Well, maybe. That problem happens when we hit the ultimate
fallback of calling the mktime() function in the C library. The
culprit is usually a misinstalled Tcl, or a tclkit that lacks the
time zone information for the local time zone - together with a
C library that complains at being asked to convert dates before the
Epoch.
What platform is this? Where did you get your Tcl interpreter?
(Is it a tclkit?) What, if anything, are the values of $env(TZ)
and $env(TCL_TZ)? Does it make a difference if you do
[clock scan] with -gmt true? Does the time zone data (the
directory $::tcl_library/tzdata) exist?
--
73 de ke9tv/2, Kevin
Adrian Davis
I'm using the latest 8.5a6 "tclkit" under XP.
"env(TZ)" and "env(TCL_TZ)" are not set. Using "-gmt true" seems to do
the trick.
Many Thanks,
=Adrian=
Regards,
=Adrian=
suchenwi
back until 1902, is clipped to 1970 from 8.5? In 8.4 we have
% clock format 0x80000000
Fri Dec 13 21:45:52 W. Europe Standard Time 1901
which I thought was a nice feature. However, with unsigned seconds
since epoch, we cross the 2037 barrier - unsigned 32-bit will extend
that to roughly the year 2104...
Times after 2037 are probably more important for the future of Tcl
than times before 1970 :^)
Andreas Leitgeb
I would call it one, if I could reproduce it.
% clock scan "12/31/1969"
-90000
% clock scan "01/01/1902"
-2145924000
% clock scan "01/01/1900"
-2208996000
Mine isn't the very latest tcl, yet, so if it failed for you with b1-rc3,
then let us know. Otherwise if yours is older than e.g. half a year,
then check again with latest.
Anyway, while experimenting on that I saw some other differences:
command: clock format 0 (with LANG=de_AT.utf-8, LANGUAGE=de,
and no LC_... vars set)
8.4 resp: Don Jän 01 01:00:00 CET 1970
8.5 resp: Thu Jan 01 01:00:00 CET 1970
Ok, that's just a l10n thing, but the next one is strange:
command: clock scan "01/01/1902"
8.4 resp: -2145920400
8.5 resp: -2145924000
These are one hour off. I don't know why, since for "01/01/1970"
they're still consistent! The day where they become different is
between 04/30/1916 (diff) and 05/01/1916 (same)
I didn't yet investigate, if this is a bug fixed since 8.4.12,
or if this reflects some real-world timezone peculiarity at that
date, which is handled in one version but not the other, or if it
is really a bug in 8.5. tcl8.4's "April 30th 1916" seems to have
been only 82800 seconds long.
If I add -gmt 1, then this difference is gone.
Eric Hassold
Below is a copy of a message I sent to you a couple of monthes ago about
this bug.
Bug doesn't occurs when compiling with recent MSVC, but happens when Tcl
is built with MingW and "older" (not that much old) MSVC compilers (I
guess that's why Andreas can't reproduce this with his version of Tcl).
It applies both to Tcl 8.5 branch and to newclock backport. The key
point is that "Posix specs says nothing about how localtime() must
handle negative epoch", so generated code vary from one compiler to another.
If you can't this mail and its attached "patch" (actually, an hack to
overload all time functions and force 64bits time_t) anymore, let me
know and I will send it back (or post it in sf.net bug tracker).
Eric
-----
Eric Hassold
Evolane - http://www.evolane.com/
----
Kevin,
We recently added newclock 1.0.1 to our eTcl distribution, and a Win32
specific bug in new implementation has been reported to us.
Using Tcl 8.4.15 with newclock or 8.5a6 (eTcl or tclkit, Win32):
% clock format -1
localtime failed (clock value may be too large/small to represent)
This woks with older clock command (8.4 branch), or on other platforms
(e.g. Linux). When calling "clock format $epoch", new clock
implementation calls localtime() directly, with epoch value as argument.
But Posix specs says nothing about how localtime() must handle negative
epoch, and of course Win32 implementation acts differently than most
other implementation, by returning error. Tcl 8.4 code handles this
correctly in tclWinTime.c, calling directly localtime() only when *tp>0,
but going through GMT first and applying timezone in Tcl code itself,
not relying on native behaviour otherwise (so [clock format -1 -gmt
true] works with newclock). Even worst, Win32 result may vary according
to compiler used for building, since when compiling with VC8 (VS2k5),
compiler forces time_t to be 64bits signed integer (time64_t), but when
compiling with mingw and VC<2k5, new clock code still uses 32bits
time_t. Explicitely forcing code to use time64_t on Win32 might be usefull.
To fix this bug in eTcl distribs, I used a quick hack to include fixes
as an header, which forces redefining time_t as int64, and provides its
own implementation of localtime(), mktime() (and some others native time
API). I send it to you as is, just for information, but fixing problem
directly into tclClock.c (and newclock.c) is of course a better way to go.
Regards,
Eric
Larry W. Virden
bauersa...@siemens.com> wrote:
>
> Times after 2037 are probably more important for the future of Tcl
> than times before 1970 :^)
I don't know, Richard. Some of us were born before 1970, so those
dates tend to be pretty important!
I did attempt to do a
clock scan 01/01/0000
just for giggles - wanted to see what tcl would think. I mean, the
months didn't exist at that point in time. I was surprised to get an
answer - but I was even more suprised to learn that a year of 0000
appears to be mapped to 2000 ...
Kevin Kenny
> command: clock scan "01/01/1902"
> 8.4 resp: -2145920400
> 8.5 resp: -2145924000
> These are one hour off. I don't know why, since for "01/01/1970"
> they're still consistent! The day where they become different is
> between 04/30/1916 (diff) and 05/01/1916 (same)
Hmm, could this have to do with the fact that Summer Time was first
observed in Germany starting at 23:00 on 30 April 1916? It's
conceivable that there is a very subtle bug in the tzdata compiler
that gives wrong times for dates before the first transition. If
so, it's quite subtle, since it does *not* fail in :America/Detroit
(the test suite checks).
I'm still recovering from a catastrophic system failure on my laptop,
so I don't yet have my environment set up to check. Log a bug so that
I don't forget. (I shan't be offended to close it as 'Invalid' if it
turns out that we have it right after all.)