[clock scan]: time value too large/small to represent

[Googie]

User of my application reported this error:

time value too large/small to represent
while executing
"ConvertLocalToUTC $date[set date {}] $TZData($timezone) 2361222"
(procedure "FreeScan" line 84)
invoked from within
"FreeScan $string $base $timezone $locale"
(procedure "::tcl::clock::scan" line 70)
invoked from within
"clock scan [lindex $1 1]"

I wonder what was passed to [clock scan] to make it report this error, because I could not reproduce the error, despite trying a lot.

What would be validation routine to make the value safe for [clock scan]?

Regards,
Pawel

[Charlie Bursell]

Why not simply put the clock scan command inside of a catch statement?

[Googie]

> Why not simply put the clock scan command inside of a catch statement?
>

Because I want to be able to point out what exactly (which part of the value) is wrong to the user.

Regards,
Pawel

[Alexandre Ferrieux]

On Aug 24, 12:32 am, Googie <pawelsal...@gmail.com> wrote:
> User of my application reported this error:
>
> time value too large/small to represent
> while executing
> "ConvertLocalToUTC $date[set date {}] $TZData($timezone) 2361222"
> (procedure "FreeScan" line 84)
> invoked from within
> "FreeScan $string $base $timezone $locale"
> (procedure "::tcl::clock::scan" line 70)
> invoked from within
> "clock scan [lindex $1 1]"
>
> I wonder what was passed to [clock scan] to make it report this error, because I could not reproduce the error, despite trying a lot.

With 8.6, look at [info errorstack] after the error. There you'll see
the actual args pass at each level on the stack.

-Alex

[Andreas Leitgeb]

Googie <pawel...@gmail.com> wrote:
>> Why not simply put the clock scan command inside of a catch statement?
> Because I want to be able to point out what exactly (which part of the value) is wrong to the user.

If you could get your customer to report his date-string along
with the error-message, then this might aid further diagnose
for the error at hand, which I suspect to be a clock-bug.
Thus, the used tcl version could be helpful as well...
And as the errorInfo points to a proc that depends on locale
information (even if just to determine the gregorian switchover),
indicating the customer's "$LANG" could be useful, too.

There's no "string is date -failindex var $str", yet, and it's
not likely for one to slip in just in time for 8.6, either. :-(

[Alexandre Ferrieux]

On Aug 25, 1:23 am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>
wrote:

Feedback ?

-Alex

[Kevin Kenny]

Your user has a Tcl installation problem, or a problem with the
local system environment, and has fallen into some last-ditch fallback
code.

This error generally crops up when Tcl has been entirely unable to
determine the rules for the local timezone, and has fallen back to using
the C library call localtime() to convert times.

Generally speaking, what Tcl goes through is the following:

(1) If the environment value TCL_TZ exists, it is used as the current
time zone.

(2) Otherwise, if the environment variable TZ exists, it is used as the
current time zone.

(3) Otherwise, on Windows, the registry path

HKEY_LOCAL_MACHINE\\System\\CurrentControlSet\\Control\\TimeZoneInformation

is examined, and time zone information is extracted from there.

(4) Otherwise, if the file /etc/localtime exists and can be interpreted
as time zone information, it is interpreted as the current time
zone.

(5) If current time zone can be found in none of the above places, then
the C library 'localtime' call will be used.

(6) If the time zone was obtained from TZ or TCL_TZ, and no such time
zone exists in either Tcl's tzdata or in /usr/share/zoneinfo,
/usr/share/lib/zoneinfo, /usr/lib/zoneinfo or
/usr/local/etc/zoneinfo (and the time cannot be parsed as a Posix
time zone specifier), then :localtime will be forced.

So your user has got down to case (5) or (6) already, which is pretty
weird right there. In addition, the user is attempting to pass a time
that is outside the range of what will fit in a time_t - either before
1 January 1970 or after some time in 2038.

The real thing to do is to find out what went wrong in steps (1)-(4)
that made the code fall into 'localtime' to begin with.

[Alexandre Ferrieux]

On Sep 1, 9:51 pm, Kevin Kenny <kenn...@acm.org> wrote:
>
>
> The real thing to do is to find out what went wrong in steps (1)-(4)
> that made the code fall into 'localtime' to begin with.

Yes, and looking at the actual values passed up the error stack is
exactly what TIP#348 allows you to do ;)

-Alex

[Alexandre Ferrieux]

On Aug 28, 11:42 am, Alexandre Ferrieux <alexandre.ferri...@gmail.com>

Ping

[Googie]

W dniu czwartek, 6 września 2012 19:04:00 UTC+2 użytkownik Alexandre Ferrieux napisał:
> > Feedback ?
>
> >
>
> > -Alex
>
>
>
> Ping

You mean you want me to give a feedback on how does it help under Tcl 8.6? Well, I cannot tell. My application is not ported to 8.6 yet.

Cheers,
Googie

[Harald Oehlmann]

On Sep 7, 12:23 am, Googie <pawelsal...@gmail.com> wrote:
> You mean you want me to give a feedback on how does it help under Tcl 8.6? Well, I cannot tell. My application is not ported to 8.6 yet.

If tcl 8.5.10+ is ok for you, you may look to:
http://wiki.tcl.tk/info errorstack

Enjoy,
Harald

[Alexandre Ferrieux]

OK, too bad :}

BTW, when you say "ported", does it mean that you have identified
some compatibility issues ? Care to share them ?

-Alex

[Rani Ahmad]

I want to add that I am in AndroWish getting the same issue when calling the
widget::calendar

I am porting my application to AndroWish from Debian GNU/Linux too.