如何调试clock.Tcl中的Tcl 8.6错误

在我们的一个NaviServer/OpenACS实例中，我们经常遇到以下错误。重新启动后，错误消失了，但会再次出现（在我还不了解的情况下）。在我看来，似乎有些代码会弄乱clock.tcl实现所使用/看到的消息目录或区域设置。但是，我不确定如何最好地调试它

expected integer but got "GREGORIAN_CHANGE_DATE"
    while executing
"GetDateFields $clockval  $TZData($timezone)  GREGORIAN_CHANGE_DATE"
    (procedure "::tcl::clock::formatproc'%Y-%m-%dT%H\:%M\:%SZ'c" line 4)
    invoked from within
"$procName $clockval $timezone"
    (procedure "::tcl::clock::format" line 34)
    invoked from within
"clock format [clock seconds] -timezone :UTC -format %Y-%m-%dT%H:%M:%SZ"

---

任何想法都将受到高度赞赏

我想你的鼻子指向了正确的方向：

% package req msgcat
1.6.1
% ::msgcat::mclocale
de_at
% ::msgcat::mcset [::msgcat::mclocale] GREGORIAN_CHANGE_DATE 2299527 
2299527
% ::msgcat::mc GREGORIAN_CHANGE_DATE
2299527
% msgcat::mclocale dummy_locale
dummy_locale
% ::msgcat::mc GREGORIAN_CHANGE_DATE
GREGORIAN_CHANGE_DATE

---

但是，

msgcat:：mclocale

似乎“损坏”了，因为没有匹配的目录条目用于关键的GREGORIAN\u CHANGE\u日期。或者，名称空间上下文可能会阻塞（在NaviServer蓝图中并非不可能）。但是，在失败之前，您需要首先跟踪

[msgcat:：mclocale]

的输出（如前面的注释所建议的）。更不可能的是，在某些（实际）语言环境中，日历转换尚未完成，并且在

clock.tcl

；）中丢失了

这可能适合您：

set毫秒[时钟点击]
可变时间[格式“%s_%03d”[时钟格式[时钟秒]-格式%Y%m%d_%H%m%s][expr{$millizes%1000}]
放置$time

因为您提到问题有时会发生，所以这听起来很有道理。问题可能是由于NaviServer/AOLserver蓝图中的命令顺序最终取决于哈希表中不可预测的顺序造成的。我在2018-06-14 12:00+0200承诺对NaviServer源代码存储库进行的更改可能可以避免此问题，因为它将：：tcl命名空间中的所有内容从蓝图中排除。它的缺点是，如果用户将内容添加到：：tcl名称空间中，这将不会包含在蓝图中。。。。但用户不应该这样做

---

背景：对于纯Tcl代码，NaviServer蓝图中的序列化顺序取决于从哈希表获得的（不稳定）顺序，因此它可能并不总是相同的。如果msgcat和时钟以任意顺序加载，则这些组件的初始化可能会混淆

您使用的是什么语言环境？

：：msgcat:：mclocale

的输出是什么？

时钟格式的实现非常复杂（在运行时生成代码），但生成的代码大多很简单。唉，在这种情况下，您所在的区域似乎缺少
GREGORIAN\u CHANGE\u DATE
信息。您的区域设置是什么？我在第744行正上方的行中输入了一个log语句，它调用引发错误的
设置日期[GetDateFields$clockval$TZData（$timezone）@GREGORIAN_CHANGE_date@
。log语句输出
[msgcat:：mclocale]
，这是
en_us
。幸运的是，管理员删除了可能正确的响应。如果可能，请取消删除它。我的第一次调试尝试将涉及自定义。