Kaifeng Lyu
Kaifeng Lyu
我这边好像是 UTC+0 。。可是 Dockerfile明明在[第三行](https://github.com/vfleaking/uoj/blob/081d0f73f618e485760bee22fac7047b77a52d70/Dockerfile#L3)就写了设成上海时间。。太奇怪了
这个更新有可能会导致兼容性问题，比如本来出题人以为自己设的是 100 / n，但更新后分值变了。 但这种情况应该只会在出题人神志不清的时候发生。。因为如果真的不一样，那么原来配置下测试点得分加起来不可能等于 100。 不过为了保险起见，我还是打算先写个小脚本看看目前 UOJ 上到底有没有这种神志不清的情况（我相信是没有的），确认无误后再来 merge hhh
问题是我也不确定客户端那边的时钟准不准嘛（还真不一定准），所以传 UTC 时间还是有可能导致倒计时有问题
很赞成，而且老版 testlib 有个 BUG（一下子找不到对应的链接了）。目前 UOJ 管理员传题，也多是使用自己上传的新版 testlib。 主要难点如下： 1. uoj 用的 testlib 是个魔改版，我记得主要魔改的地方是 registerInteraction 的部分。可能需要 diff 一下还有没有别的地方被魔改了 2. 以前上传的题目在 testlib 更新后，最好重新生成一遍数据包，并检查题目是否还能正常评测。感觉有点工程量。。（这也是 UOJ 的 testlib 一直都没有更新的主要原因）
社区版的做法确实不错，不过这样每次打开题目，UOJ 都得去跟文件系统交互。感觉理想情况下这个信息还是应该存在数据库里
感谢，不过这个实现有点问题，应该在每次rejudge之后，判断这次rejudge是不是由一个hack导致的，并且hack还导致submission丢分了。目前的这个实现是在一次hack成功后整题重测前发送的，可能会漏掉其他因为该hack而丢分的submission