stanfordnlp/CoreNLP · warning

Failed to process timex

Error message

Failed to process timex 

What it means

A logged warning in toCoreMaps: after attributes were collected, Timex.fromMap(text, timexAttributes) itself threw. The code logs 'Failed to process timex <text> with attributes <map>' (when verbose), skips the expression via continue, and no TimexAnnotation is set. Unlike the previous catch, the attributes map exists but converting it into a Timex object failed.

Solutions

  1. Enable sutime.verbose and inspect the logged attributes map to see which key/value upset Timex.fromMap
  2. Correct the SUTime rule so it emits standard attributes (value, altVal, tid, type, begin/end)
  3. Upgrade Stanford CoreNLP; Timex.fromMap and SUTime attribute handling have been hardened over releases
  4. As a workaround, post-filter: detect CoreMaps lacking TimexAnnotation and handle them downstream
Defensive patterns

Strategy: validation

Validate before calling

// verify every produced CoreMap carries a Timex annotation before consuming it
for (CoreMap cm : coreMaps) {
  if (cm.get(TimeAnnotations.TimexAnnotation.class) == null) {
    log.warn("Missing Timex for: " + cm); // handle/fallback
  }
}

Prevention

When it happens

Trigger: extractTimeExpressionCoreMaps -> toCoreMaps with a timexAttributes map that Timex.fromMap cannot consume — e.g. missing/odd 'value' or 'tid' entries produced by a broken rule, or text that defeats Timex's string handling.

Common situations: Custom SUTime rule sets emitting attributes that violate Timex expectations; annotating noisy OCR/HTML-derived text; version drift where Timex attribute keys changed but custom rules still emit old keys.

Understand the failure class

Background: "invalid response format", "malformed payload", "missing data field": when an API returns 200 but the response shape is wrong — this error's family across 23 libraries.

Related errors


AI-assisted analysis of stanfordnlp/CoreNLP@1b7edd19c4 (2026-09-10). Data as JSON: /api/errors/6fccc5ba4a830fdc. Report an issue: GitHub.

Appendix: source

Thrown at src/edu/stanford/nlp/time/TimeExpressionExtractorImpl.java:161

          if (options.includeRange) {
            SUTime.Temporal rangeTemporal = temporal.getRange();
            if (rangeTemporal != null) {
              timexAttributes.put("range", rangeTemporal.toString());
            }
          }
        } catch (Exception e) {
          if (options.verbose) {
            logger.warn("Failed to get attributes from " + text + ", timeIndex " + timeIndex);
            logger.warn(e);
          }
          continue;
        }
        Timex timex;
        try {
          timex = Timex.fromMap(text, timexAttributes);
        } catch (Exception e) {
          if (options.verbose) {
            logger.warn("Failed to process timex " + text + " with attributes " + timexAttributes);
            logger.warn(e);
          }
          continue;
        }
        assert timex != null;  // Timex.fromMap never returns null and if it exceptions, we've already done a continue
        cm.set(TimeAnnotations.TimexAnnotation.class, timex);
        coreMaps.add(cm);
      }
    }
    return coreMaps;
  }

  public List<TimeExpression> extractTimeExpressions(CoreMap annotation, String refDateStr, SUTime.TimeIndex timeIndex) {
    SUTime.Time refDate = null;
    if (refDateStr != null) {
      try {
        // TODO: have more robust parsing of document date?  docDate may not have century....
        // TODO: if docDate didn't change, we can cache the parsing of the docDate and not repeat it for every sentence

View on GitHub (pinned to 1b7edd19c4)