Chronometrica vs Techforce Facebook Public Comments: Which Saves Available Comment Dates?

Start with the date you need to save

The reader’s question is direct: how can you save the exact time of a Facebook comment? The public request concerns retaining a comment date instead of keeping only relative minutes or hours. It is a date-preservation problem. Original reader question

Before you choose an Actor, write down what “time” means for your project. Two different events can have dates:

• The person published the comment.
• The collection program saved the comment.

Those events can happen days or months apart. A collection date cannot tell you when the person wrote the comment.

Next, decide how much date detail the work requires. You might need a calendar date for a daily review. You might need an exact time to establish event order. A value that meets the first need may fail the second.

Make that requirement clear before you collect data. For example: “Each accepted comment must have a public publish date. Comments without one stay in a separate review group.” That rule permits useful dated records while keeping missing dates visible.

A stricter rule could require an exact publish time on every row. That changes the choice because a field that permits missing values cannot, by itself, meet the rule. First check what the public source exposes. Then check whether the saved value has the detail you need.

Compare the contracts against that requirement

A contract here means the documented inputs, output fields, and limits of an Actor. This comparison uses public contracts checked on October 20, 2026. It reports no new collection run or measured performance result.

Sources: Chronometrica’s public contract, Techforce’s public contract.

Start with the required field, then check the input route. A date field does not help if you cannot supply a supported source. A supported source does not help if the output omits the field your decision requires.

Choose the smaller contract when it meets the whole requirement. Do not add date handling to a project that needs only text. Equally, do not remove a date requirement just because another export is easier to start.

Keep publish time and collection time separate

Chronometrica provides two fields with different meanings. `publishedAt` holds the available comment publish date. `scrapedAt` records collection time. Keep both fields under their original names when you first review the export. Chronometrica output fields

Use `publishedAt` to decide whether a comment has a date that meets your rule. Use `scrapedAt` to record when collection occurred. The second field can help you track collection work. It cannot fill a missing value in the first field.

Treat `null` as a missing value. In a spreadsheet, you may display it as an empty cell. Keep its meaning clear in your working notes and any later export. Do not turn it into zero, the collection date, or a made-up default date.

Also keep the difference between a relative label and an exact date. A label such as “2 hours ago” describes time relative to another moment. It is not the same evidence as a public exact timestamp. Do not subtract two hours from collection time and present the result as the comment’s exact publish time.

If a saved date has a time, inspect any time-zone information before you compare it with another date. If that information is missing, record the uncertainty. Do not assume that two displayed times use the same time zone.

These checks protect the meaning of the data. A column can look complete after you fill its empty cells, while the underlying publish dates remain unknown. Keep unknown dates visible so the next person can judge the result correctly.

Set up a small collection from a known thread

Chronometrica requires known content URLs for this job. Its input accepts 1–100 public post, Reel, video, or photo links. The checked schema also supports short and share links. Page, Group, profile, Story, and private links are outside this input route. Chronometrica input schema

The published Facebook Comments and Replies Export Task offers a starting preset. A Task is a saved input preset for an Actor. Opening the Task page does not establish which input values are currently saved. Review the input before you run it.

The following example passed a static check against the supplied public schema. A static check verifies the input’s shape and allowed values. It does not collect comments or prove that the example source is available now.

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

Replace the example URL with your intended public source. Here, `maxResultsPerPost` sets a limit of 100 saved results for that URL. It does not promise 100 results. The checked schema permits limits from 1 to 10,000. Chronometrica input limits

The example sets `includeReplies` to `false`. If your project needs replies, change it to `true`. Replies are separate paid rows and count toward the same result limit for each URL. Choose this setting from the scope of your question. A review of top-level comments and a review of whole conversations have different needs. Chronometrica reply settings

Use four acceptance checks before you rely on the export

An acceptance check is a rule you use to decide whether the output meets your need. Write these rules before the first run. This avoids changing the standard after you see the data.

1. Name the required date

Write whether you need publish time or collection time. If you need publish time, name `publishedAt` in the rule. Keep `scrapedAt` for its separate collection purpose.

Also state the required detail. “A calendar date is enough” and “an exact time is required” are different rules. If you need a time zone, include that in the rule too.

For a small review, a short sentence is enough. For shared work, put the rule beside the export so another person can apply it without guessing.

2. Inspect saved values before changing them

Keep an original copy of the output. Review `publishedAt` and `scrapedAt` in separate columns. Check a few populated dates and every missing publish date in a small sample.

Look for values that your spreadsheet may display differently from the saved data. A shortened cell display can hide time detail. A blank cell can hide the fact that the original value was `null`. Inspect the saved value before you decide what it means.

If you change the display format, preserve the original value. A clearer display should not add precision that the source did not provide.

3. Account for missing publish dates

Count the saved rows. Then count rows whose publish dates meet your rule and rows that do not. Keep uncertain values separate until you resolve them.

These groups should account for the whole export. This catches rows that disappear during filtering. It also makes the result easier to explain: some comments support the date-based work, while others remain undated or uncertain.

A completeness figure for your sample can describe that sample. It does not establish the result you will get from another thread. Do not turn one successful sample into a promise about future sources.

4. Make the acceptance decision explicit

If missing dates are allowed, retain those comments with their missing values. State whether your later analysis includes or excludes them.

If every row needs a qualifying date, one missing or unresolved value prevents that export from meeting the rule. Collecting more rows does not resolve the missing date on an existing row.

For work that later groups comments by whether a question received an answer, use How to Find Unanswered Questions in Facebook Comments. That guide covers the broader review method. Complete the date check first when time affects your question.

A fictional example: three comments, two usable dates

This example is fictional. It is not a product test, buyer result, live dataset, or measured cost result. The dates below illustrate an acceptance decision. They do not show an actual Actor response format.

A researcher wants to place three saved comments in date order. Their rule permits missing dates, but undated comments must stay outside the dated sequence.

1. The first fictional comment has a `publishedAt` value for October 18, 2026, at 09:15 UTC. Its `scrapedAt` value records collection on October 20, 2026, at 12:00 UTC.
2. The second has a `publishedAt` value for October 18, 2026, at 10:05 UTC. Its `scrapedAt` value records the same collection time.
3. The third has `publishedAt: null`. Its `scrapedAt` value also records that collection time.

UTC is a common time reference. In this invented example, both publish times use it, so the researcher can compare them directly.

The first comment precedes the second. The third comment has no known position in that sequence. Its collection time does not place its publication after the other two comments.

The check accounts for all three rows: two have usable publish times, and one has a missing publish time. The researcher keeps the third row in an undated group. They do not assign it midnight or October 20.

Under the stated rule, the export can support a dated sequence for two comments while preserving the third for separate review. If the rule changes to require an exact publish time for all three, the export fails that requirement.

If the fictional project instead needs Page-led text and usernames without dates, Techforce’s smaller text contract fits. Techforce Facebook Public Comments

Let the missing-date rule decide the recommendation

Chronometrica fits the checked need when you have supported public content URLs, want available comment publish dates, and can retain missing dates as `null`. Its separate date fields let you preserve the distinction between publication and collection. Chronometrica Facebook Comments Scraper

The main switch condition is whether unavailable publish dates are acceptable. If they are, a nullable field can support the work. If every exact hover date is mandatory, the checked documentation is insufficient to approve that requirement.

Do not choose based on an assumed speed, accuracy, coverage, or cost advantage. This comparison contains no matched run and no approved price calculation. Its supported distinction concerns inputs, documented fields, and missing-date handling.