Chronometrica 与 Techforce Facebook Public Comments：哪个能保存可获取的评论日期？

先明确你需要保存哪种日期

读者的问题很直接：怎样才能保存 Facebook 评论的精确时间？这条公开提问关注的是保留评论日期，而不只是保留几分钟前或几小时前这样的相对时间。这是一个日期保留问题。读者的原始提问

选择 Actor 前，先写清楚项目中的“时间”指什么。以下 2 个不同事件都可以有日期：

• 用户发布评论。
• 采集程序保存评论。

这 2 个事件可能相隔数天或数月。采集日期无法说明用户何时写下评论。

接着，确定这项工作需要多精细的日期信息。按天审核时，你可能只需要年月日。确定事件先后顺序时，你可能需要精确时间。满足前一种需求的值，未必能满足后一种需求。

采集数据前，先明确这项要求。例如：“每条通过验收的评论都必须有公开的发布日期。没有发布日期的评论应放入单独的审核组。”这条规则既允许使用有日期的有效记录，也让缺失日期保持可见。

更严格的规则可能要求每条记录都有精确的发布时间。这会改变工具选择，因为仅靠一个允许缺失值的字段，无法满足这条规则。先检查公开来源提供了哪些信息，再检查保存的值是否足够精细。

按需求比较功能约定

这里的功能约定指 Actor 文档中列出的输入、输出字段和限制。本次比较使用的是在 2026 年 10 月 20 日核查的公开功能约定。本文没有报告新的采集运行，也没有报告实测性能结果。

来源：Chronometrica 的公开功能约定、Techforce 的公开功能约定。

先确定所需字段，再检查输入方式。如果你无法提供受支持的来源，即使工具有日期字段也没有帮助。如果输出不包含决策所需的字段，即使来源受支持也没有帮助。

如果较小范围的功能约定能满足全部需求，就选择它。只需要文本的项目，不必增加日期处理。同样，也不要因为另一种导出更容易上手，就取消日期要求。

区分发布时间与采集时间

Chronometrica 提供 2 个含义不同的字段。`publishedAt` 保存可获取的评论发布日期。`scrapedAt` 记录采集时间。首次审核导出数据时，请保留这 2 个字段的原始名称。Chronometrica 输出字段

用 `publishedAt` 判断评论是否有符合规则的日期。用 `scrapedAt` 记录何时进行了采集。后一个字段可以帮助你跟踪采集工作，但不能用来填补前一个字段的缺失值。

将 `null` 视为缺失值。在电子表格中，你可以将它显示为空白单元格。在工作备注和后续导出中，都要明确保留它的含义。不要将它改成 0、采集日期或虚构的默认日期。

还要区分相对时间标签与精确日期。“2 小时前”这样的标签描述的是相对于另一个时刻的时间。它与公开的精确时间戳不是同一种证据。不要从采集时间减去 2 小时，再将结果当作评论的精确发布时间。

如果保存的日期包含具体时间，先检查其中的时区信息，再与另一个日期比较。如果缺少时区信息，请记录这一不确定性。不要假定 2 个显示的时间使用同一时区。

这些检查可以防止数据含义被改变。填满空白单元格后，一列数据看起来可能完整了，但实际发布日期仍然未知。让未知日期保持可见，后续使用者才能正确判断结果。

从已知评论串开始小规模采集

完成这项任务时，Chronometrica 需要已知的内容 URL。输入接受 1–100 个公开帖子、Reel、视频或照片链接。已核查的输入规范也支持短链接和分享链接。公共主页、小组、个人主页、Story 和私密链接不在此输入方式的支持范围内。Chronometrica 输入规范

已发布的 Facebook 评论与回复导出 Task 提供了一组可用作起点的预设。Task 是为 Actor 保存的输入预设。仅打开 Task 页面，并不能确认当前保存了哪些输入值。运行前请检查输入。

以下示例已按所提供的公开输入规范通过静态检查。静态检查会验证输入结构和允许的值。它不会采集评论，也不能证明示例来源目前仍可访问。

{
  "startUrls": [
    "https://www.facebook.com/reel/1733966934399341"
  ],
  "maxResultsPerPost": 100,
  "includeReplies": false
}

将示例 URL 替换为你计划使用的公开来源。在这里，`maxResultsPerPost` 将该 URL 的已保存结果数上限设为 100。这不保证一定返回 100 条结果。已核查的输入规范允许设置 1 至 10,000 的上限。Chronometrica 输入限制

示例将 `includeReplies` 设为 `false`。如果项目需要回复，请将它改为 `true`。回复按单独的记录行计费，并计入每个 URL 的同一个结果数上限。请根据问题范围选择此设置。审核顶层评论与审核完整对话的需求不同。Chronometrica 回复设置

使用导出数据前，先完成 4 项验收检查

验收检查是用来判断输出是否满足需求的规则。首次运行前，请先写下这些规则。这样可以避免看到数据后再改变标准。

1. 明确所需日期

写清楚你需要发布时间还是采集时间。如果需要发布时间，请在规则中明确写出 `publishedAt`。保留 `scrapedAt`，仅用于记录采集时间。

还要说明所需的精细程度。“有年月日即可”和“必须有精确时间”是不同的规则。如果需要时区，也要将其写入规则。

小规模审核只需写一句简短说明。多人协作时，请将规则放在导出数据旁边，让其他人无需猜测就能应用。

2. 修改前先检查已保存的值

保留一份原始输出副本。将 `publishedAt` 和 `scrapedAt` 放在不同列中审核。在一个小样本中，检查几个已填入的日期，以及所有缺失的发布日期。

注意电子表格的显示可能与实际保存的值不同。单元格内容被缩短显示时，可能隐藏具体时间。空白单元格可能掩盖原始值为 `null` 的事实。判断含义前，请先检查保存的值。

如果修改显示格式，请保留原始值。更清晰的显示不应增加来源未提供的精度。

3. 核对缺失的发布日期

先统计已保存的记录行数。再分别统计发布日期符合规则和不符合规则的记录行数。对不确定的值单独分组，直到查明为止。

这些分组应覆盖整个导出数据集。这样可以发现筛选过程中遗漏的记录，也更容易解释结果：部分评论可用于按日期开展的工作，其他评论仍缺少日期或存在不确定性。

样本的完整率只能描述该样本，不能说明你从另一个评论串会获得什么结果。不要将一次成功的样本采集当作对未来来源的保证。

4. 明确验收结论

如果允许日期缺失，请保留这些评论及其缺失值。说明后续分析是否包含这些评论。

如果每条记录都需要符合要求的日期，那么只要有 1 个缺失或尚未查明的值，整个导出数据集就不符合规则。采集更多记录，无法补上已有记录中缺失的日期。

如果后续工作需要按问题是否得到回答来对评论分组，请参阅如何查找 Facebook 评论中未获回答的问题。该指南介绍了更完整的审核方法。如果时间会影响你的问题，请先完成日期检查。

虚构示例：3 条评论，2 个可用日期

这是一个虚构示例。它不是产品测试、买家实际结果、实时数据集或实测成本结果。以下日期用于说明如何作出验收决定，并不表示 Actor 的实际响应格式。

一名研究人员希望将 3 条已保存的评论按日期排序。规则允许日期缺失，但没有日期的评论必须排除在日期排序之外。

1. 第 1 条虚构评论的 `publishedAt` 值为 2026 年 10 月 18 日 09:15 UTC。其 `scrapedAt` 值记录的采集时间为 2026 年 10 月 20 日 12:00 UTC。
2. 第 2 条评论的 `publishedAt` 值为 2026 年 10 月 18 日 10:05 UTC。其 `scrapedAt` 值记录了相同的采集时间。
3. 第 3 条评论为 `publishedAt: null`。其 `scrapedAt` 值也记录了该采集时间。

UTC 是一种通用的时间基准。在这个虚构示例中，2 个发布时间都使用 UTC，因此研究人员可以直接比较。

第 1 条评论早于第 2 条。第 3 条评论在这一顺序中的位置未知。它的采集时间不能说明它发布于另外 2 条评论之后。

检查覆盖了全部 3 条记录：2 条有可用的发布时间，1 条缺少发布时间。研究人员将第 3 条记录保留在无日期组中，不会给它指定午夜或 10 月 20 日作为发布时间。

根据既定规则，这份导出数据可以支持对 2 条评论按日期排序，同时保留第 3 条评论供单独审核。如果规则改为要求全部 3 条评论都有精确发布时间，这份导出数据就不符合要求。

如果这个虚构项目只需要以公共主页为起点获取文本和用户名，不需要日期，那么 Techforce 较小范围的文本功能约定就能满足需求。Techforce Facebook Public Comments

根据日期缺失规则决定推荐方案

如果你有受支持的公开内容 URL，需要保存可获取的评论发布日期，并且可以将缺失日期保留为 `null`，那么 Chronometrica 符合本次核查的需求。它用不同字段保存日期，让你能够保留发布与采集之间的区别。Chronometrica Facebook Comments Scraper

改变选择的主要条件，是能否接受无法获取的发布日期。如果可以，允许空值的字段就能支持这项工作。如果必须保存每条评论在鼠标悬停时显示的精确日期，已核查的文档不足以确认工具满足这一要求。

不要根据假定的速度、准确性、覆盖范围或成本优势作出选择。本次比较没有进行同条件运行，也没有经批准的价格计算。有依据的差异仅涉及输入、文档列出的字段，以及日期缺失的处理方式。