最担心的事情终于来了，运营终于弄了 半点开始的排名赛 ，甚至还在里面塞了 大量的紧急 。
于是很喜闻乐见的，时间表没法处理这种紧急了，只能显示出排名赛。
而且时间表的逻辑也没考虑到会出现半点开始的排名赛，12:30 开始， 2:30 结束这种也只能识别为 12:00 开始，2:00 结束。
反正这周处理出的时间表基本是处于不可用的状态了。
这个时间表当初是作为 JavaScript 入门随便瞎搞的，只用了原生 js 以及 jQuery，没有用到目前主流的框架。
甚至前端的实现方式还不是用的动态创建元素，而是十分无脑的 html 内容填充。
虽然用 Python 写的后端至今为止也就因为官网大改版重写了一次，没遇到什么大的问题。
目前来说要在时间表的前端部分再修修补补也不太现实了，当初设计时根本就没想太多。
反正我代码写得渣嘛，嗯哼。
Then
基于以上原因，时间表的前端部分大概要进行一次重写。
之前想做的时区转换，紧急过滤，一键生产时间表图片之类的由于当前代码的限制，做起来十分困难。不过重写之后应该会好点了吧。
官网用 list 模拟 table 的实现方式让我挺感兴趣的，而且这样也能跳出合并单元格时不停 colspan rowspan 的怪圈。
半点紧急之类的对应也可以做得相当灵活了，反正肯定比现在的好。重写的时候主要会注意可扩展性之类的。
后端数据目前没有太大问题，所以工作量应该不会太大。
不过什么时候出成品大概是未知数了。咕咕咕。
这周固定时间表就拜托 Swiki 老师了。虽然随机紧急没有什么问题，所以可以继续用。
也许还会考虑优化手机访问时间表时的体验。咕咕咕咕咕咕咕咕咕咕
One more thing
也许有人已经注意到了，昨天傍晚的时候紧急表 稍微中断了一会儿然后 开始使用 HTTPS 了
这主要是因为在 Chrome 62 版本以后，非 HTTPS 不再支持发送桌面通知，也就意味着 我主打的 通知功能废了。
所以我上了 HTTPS，就这么简单（
对正常使用应该是没有影响的，不用过分在意。