Spec 的数据结构中 year 允许为空不合理 about gb2260 HOT 20 CLOSED

我也觉得显式的比隐式的要好，spec中这个year对应的数据信息，从后面的例子上看应该是一个string的值，而string在有些强类型语言（如Go）中，默认是没有nil/None/null这类的，都是一个空的字符串，这样实际上是违背了spec中的定义。

对于latest year，我目前的代码是写死在代码中的，即2014，对于Go代码中，目前我的实现是:

NewGB2260("").Get("110103").Year 是返回2014的。

from gb2260.

更新了 spec v0.2，可以先讨论一下。

from gb2260.

其次，对 year 的这种处理，实际上是重载了这一字段的含义。使其不再表示单一的「年份版本」，同时还表示了「是否是最新版本」。

赞同考虑。

提供一个参考措施：出于显式胜于隐式的考虑，废弃 latest 这种查询方法。

如果用户代码中需要查询的区域使用哪一年的标准是未知的，那么遍历所有 revision 的 search 接口才是他们需要的。latest 并不是必须。

from gb2260.

可以暴露出一个 latest revision，根据各自的语言特性来决定。

from gb2260.

可以暴露出一个 latest revision，根据各自的语言特性来决定。

个人认为没有必要

from gb2260.

可以暴露出一个 latest revision，根据各自的语言特性来决定。

个人认为没有必要

希望有一个办法比较 revision 的大小，例如比较 GB2260-2003、GB2260-200306 中的 2003 与 200306 的大小。

from gb2260.

1. 比较前 4 位数字
2. 前 4 位一样，长度为 4 的 revision 更大

from gb2260.

@gaomd 可以直接用 pkg_resources.parse_version

好吧不可以……

from gb2260.

这么一说，感觉 GB2260-200306 实际上也表达了两个意思。一个是我们自己给它编的版本号是 "200306"，一个是这个版本更新的时间是 datetime(2003, 6, 30)。（200306 把日给扔掉了，来源里面是精确到日的）

from gb2260.

不如版本号改成完整的日期

from gb2260.

@lepture 不赞成…… 那样就和上游（国家统计局）的版本号对不上了

其实是需要实现一个版本比对的函数（类似 pkg_resources.parse_version），就像 v1.0.1 大于 v1.0，你不要要求别人把 v1.0 一定写成 v1.0.0……

from gb2260.

@tonyseek https://github.com/cn/GB2260.js/blob/spec-0.2/scripts/generate.js#L52

类似这样的比较？

from gb2260.

@lepture 是的，切字符串或者正则表达式都可以。setuptools 也是正则表达式切的版本号

from gb2260.

版本返回 (year, month) 就可以了，没有 month 的话就是最大的。

from gb2260.

@lepture 不是所有语言都有 tuple，是否应该加个 Revision 结构用于比较？

from gb2260.

@tonyseek 我觉得需要的是比较函数，而不是 Revision 结构

from gb2260.

赞成加个 Revision 结构，不仅是为了比较，更重要的是，我觉得每个版本的 metadata 也是重要的数据。200306 版本统计的究竟是截止到 1 号还是 30 号并不是无关紧要的。

比如 Revision 序列化成 JSON 可以是：

{
    "revision": "200306",
    "revised_at": "2003-06-30T00:00:00+0800"
}

from gb2260.

@timothyqiu 原始数据的日期并不是很重要的数据，都是截止到月末的。

from gb2260.

@lepture 国家标准化管理委员会的网站上有具体发布、实施日期可查，不过可惜 2260 只有 2007 和 2002 版本。

http://www.sac.gov.cn/SACSearch/outlinetemplet/gjbzcx.jsp

from gb2260.

先关掉这个 issue，原始问题已经解决，输入 revsion 是必须的。

from gb2260.