【发布时间】：2011-04-05 09:16:21
【问题描述】：
按需生成 RSS 提要。
据我所知，因为我有两个 lastBuildDate 选项 - 当前时间或 pubDate。
你会选择哪一个，为什么？
【问题讨论】：
-
您是在使用任何类型的缓存，还是真的在按需构建“实时”？
-
@Pekka 它充当常规 php 脚本，按需生成。
【发布时间】：2011-04-05 09:16:21
【问题描述】：
根据RSS 2.0 spec,lastBuildDate是频道内容最后一次改变。 （我对这个定义并不完全满意，因为如果提要的元数据发生变化怎么办？我认为常见的约定是在这种情况下更新lastBuildDate。）
频道范围内的pubDate 应该用于供稿中项目的原始发布日期。使用lastBuildDate 从来都不是一个好的值，因为即使项目更新，pubDate 也会保持不变。
使用当前时间是简单的出路，但并不完美（因为更改了lastBuildDate，客户端可能会启动不必要的操作）
最好的方法是真正知道/找出提要的内容上次更改的时间，然后输出。
【讨论】：
-
是的，我从谷歌看到了这个相关的问题，应该提到它。实际上，这是我之前针对此任务提出的问题 :) 那么，您投票支持与整个 RSS 的 pubDate 相同的值吗？
-
@Col 不，我真正的投票将是最后一次 real 更改整个提要（项目 + 任何元数据）的日期。如果这不可能，则为当前时间。
-
看，它只是一个简单的站点新闻 RSS。假设它的项目一旦发布就永远不会改变。并且没有其他信息可以更改。只是简单明了的单向馈送。因此，我们可以假设 max item 的 pub date 是实际的 feed 更改时间。我也应该提到它。假设这一点，您仍然是整个站点的 PubDate 值，对吧？
-
@Col 如果就这么简单，我会像@shamittomar 所说的那样投票支持使用最大 pubDate。在这种情况下不需要任何更复杂的东西。如果可能的话，如果没有内容更改，我会避免更改
lastBuildTime。 -
完全省略这一项似乎是明智的选择。不这么认为，但它似乎很合乎逻辑 - 如果你不知道在可选字段中输入什么 - 就不要使用它！
具有最新 PubDate 的项目应成为 lastBuildTime。
[编辑]：如果您也为整个提要使用单独的 PubDate，那么 lastBuildTime 应该是当前时间 因为您是在当前时间按需构建它 :) .
[编辑]：2：：由于lastBuildTime 是可选的，而且您无论如何都将 PubDate 包括在整个提要中，为什么不将其从提要输出中删除？
【讨论】：
-
但整个提要也有 pubDate。有你的建议，这就是为什么我对 lasBuildDate 有疑问