Re: [naviserver-devel] Clock.tcl repeat initialisation after ns_eval

[David O. <da...@qc...>]

On 8 July 2013 17:16, Gustaf Neumann <ne...@wu...> wrote:

> The problem is not only the caches (otherwise it would have been
> sufficient to exclude the ::tcl::* namespaces from the blueprint), but
> also the definition of proc "clock", which redefines itself in terms of
> an ensemble. This makes it sensitive to the definition order.
>

So should the exclusion of ::tcl from the blueprint mean there should be no
::tcl::clock variables defined from the previous invocations of
::tcl::clock commands in the interpreter after an ns_eval?


> Btw, my impression is that when ":localtime" is used instead of
> ":Tcl/Localtime" ....
>
> proc clock_test {} {
>      ns_log Notice [clock format [clock scan now] -format "%Y-%m-%d
> %H:%M:%S" -timezone :localtime]
>      return true
> }
>
> ... then everything is fine even when we do not exclude "proc clock"
> from the blueprint. Can you check this?
>

Yes. It's very easy to work around the error.

If you call "clock format" with no timezone option at all, the same error
happens but is wrapped in a "catch".
The timezone is defaulted to :Tcl/Localtime. This is set as
CachedSystemTimeZone. After a ns_eval, the clock code tries to lookup
:Tcl/Localtime in TZData, it's not there so it marks it as a BadTimeZone.
The difference is that it then proceeds to fall back to using :localtime
instead. But :Tcl/Localtime is still flagged as a BadTimeZone.

So we can operationally get round this. We were just concerned it was
exposing a bug.
Whether or not it needs fixing, is definitely debatable!

-- 
David Osborne