RFC 4880是一个描述OpenPGP加密标准的文档，其根源于RFC 2440，发布于1998年（那是 16年前，据说是在64位之前系统出现了）。这两个规范都说明了时间戳的处理方式：
3.5。时间字段
时间字段是包含该数字的无符号四个八位字节数 自UTC时间1970年1月1日午夜起经过的秒数。
是否应该尽可能地关注RFC （并且，在这里，有一天会面临甜蜜的year 2038 bug）？如果开发人员不遵守标准/规范/ RFC的部分内容（特别是在加密方面），当它们被认为已经过时时，它是否“有风险”？
我有点害怕问，因为这个问题听起来很愚蠢，但如果我“实施RFC 4880”，但以我自己的方式，它不再是官方的事情了。那么，开发人员应该对她所看到的“过时”规范部分做些什么？什么都没有？
答案 0 :(得分：2)
首先：我认为你问题中的例子是错误的。 RFC4880 使用无符号 32位整数。 y2k38问题是签名 32位整数的问题。根据维基百科的说法，无符号的32位整数可以工作到2106年。多一点时间。
回答你的问题： 我认为最好的方法是与RFC工作组/ RFC的作者联系，并告诉他们过时的情况。也许，后续RFC将解决这个问题。
对于您的示例，我认为您可以避免联系OpenPGP WG。我想，直到2106会有很多更新，我怀疑V5键有8个八位字节的时间字段。