La versión pública 0.1.30 de X Search admite queries (de 1 a 20), searchMode (latest, top, photos, videos), maxItemsPerQuery (de 1 a 1000) y cadenas de fecha opcionales para startTime y endTime. Reemplace toda la lista guardada de 2 consultas por la consulta y el intervalo de fechas que desea usar, con maxItemsPerQuery 2 y searchMode latest para su primera comprobación de alcance limitado. Use los campos nativos startTime y endTime 1 vez, sin duplicar filtros since o until dentro de la consulta y sin inventar parámetros expansion, includeReplies o page.
La entrada de control actual usa from:OpenAI con startTime 2026-07-07 y endTime 2026-07-09, lo que generó la consulta ejecutada from:OpenAI since:2026-07-07 until:2026-07-10. En las posiciones 2 y 3, había 2 registros de respuestas del 9 de julio con identificadores de autor y valores createdAt en UTC correctos. También se registró un total de 1 exclusión por outsideTimeRange, sin identificadores excluidos. Esto demuestra que el flujo de trabajo comprobado funciona, pero no verifica todos los operadores ni una cobertura histórica completa.
Los campos nativos que usa la herramienta incluyen inputQuery, executedQuery, searchMode, resultPosition, postId, postUrl, text, createdAt, authorId, authorHandle, authorUrl, isReply, isQuote, isRepost y observedAt. En la salida, searchMode usa Latest con mayúscula inicial, mientras que los valores enumerados de entrada están en minúsculas. No hay un campo de estado por registro en el conjunto de datos.
Pasos para realizar búsquedas delimitadas por fecha
- Escriba la frase y el intervalo de fechas que desea buscar antes de ejecutar cualquier script. Mantenga maxItemsPerQuery en un valor bajo y searchMode en latest para una comprobación piloto.
- Reemplace la lista de consultas de ejemplo por una sola cadena de consulta, un límite máximo de dos elementos y cadenas para los campos nativos startTime y endTime. No agregue términos since o until duplicados dentro de la cadena de consulta.
- Guarde las cadenas inputQuery y executedQuery. Por ejemplo, una solicitud que termina el 9 de julio genera un límite superior exclusivo del 10 de julio, como until:2026-07-10.
- Interprete las marcas de tiempo nativas de createdAt y compruebe si están dentro de un intervalo UTC explícito. Las etiquetas que solo muestran fechas en pantalla no establecen una zona horaria local, salvo que usted haga la conversión.
- Cuando falten marcas de tiempo, mantenga esos casos como no resueltos en lugar de adivinar. Si createdAt está vacío, no se puede usar observedAt para ubicar la publicación en orden cronológico, ya que solo registra el momento de recopilación.
- Compruebe los identificadores de autor, los nombres de usuario y los tipos de publicación, como respuestas, citas o republicaciones. Una publicación de un autor puede ser una respuesta en lugar de una publicación original independiente.
- Revise los campos de nivel superior de OUTPUT, como searchesQueued, searchesStarted, rowsSaved, outsideTimeRange, statusCounts y stopReason, junto con el arreglo queries que contiene inputQuery, executedQuery, status, rowsSaved, outsideTimeRange y stopReason. En el nivel superior, queries_exhausted significa que terminó el procesamiento de la cola, no que se agotaron todas las publicaciones de la fuente que coinciden con la búsqueda. En cambio, max_items_per_query para una consulta significa que la muestra alcanzó el límite de esa consulta. Mantenga separados los resultados fallidos, vacíos y limitados por el máximo de elementos. Además, conserve los saltos en las posiciones de la fuente en lugar de reasignar posiciones a los registros recopilados.
- Entregue su registro con fechas junto con los comprobantes de los datos de entrada y los recuentos de exclusiones. No suponga que una muestra pequeña representa la frecuencia total en la plataforma ni la popularidad histórica.
Ejemplo ficticio original para comprobar los límites de fecha en UTC
La siguiente tabla es un caso de prueba ficticio original para comprobar los límites de fecha en UTC de un intervalo del 1 al 4 de octubre. UTC significa tiempo universal coordinado. Un intervalo semiabierto incluye su hora de inicio, pero excluye su límite superior. Según la convención comprobada para fechas sin hora, solicitar un intervalo del 1 al 3 de octubre, ambos inclusive, corresponde a un inicio el 1 de octubre a las 00:00 UTC y un límite superior exclusivo el 4 de octubre a las 00:00 UTC. El endTime nativo solicitado del 3 de octubre y el until generado del 4 de octubre se mantienen como valores distintos. Este es un caso de prueba para que el lector haga la comprobación; no son datos en vivo de la prueba de control del Actor.
| ID de la publicación | Fecha y hora de creación (UTC) | Fecha y hora de observación | Estado respecto del intervalo |
|---|---|---|---|
| CandidateP1 | 2026-10-01 00:00:00 | 2026-10-01 01:00:00 | Dentro |
| CandidateP2 | 2026-10-03 23:59:59 | 2026-10-04 00:00:00 | Dentro |
| CandidateP3 | 2026-10-04 00:00:00 | 2026-10-04 01:00:00 | Fuera |
| CandidateP4 | null | 2026-10-03 12:00:00 | Sin resolver |
Este caso de prueba muestra 2 registros dentro del intervalo, 1 fuera y 1 sin resolver con una fecha de creación nula. Una muestra recopilada puede omitir publicaciones anteriores. Por eso, si falta una publicación, significa que no se observó en la muestra, no que no exista en X.
Fuentes y lecturas adicionales
Por Chronometrica · Actualizado
Volver arriba ↑
