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
- Enable sutime.verbose and inspect the logged attributes map to see which key/value upset Timex.fromMap
- Correct the SUTime rule so it emits standard attributes (value, altVal, tid, type, begin/end)
- Upgrade Stanford CoreNLP; Timex.fromMap and SUTime attribute handling have been hardened over releases
- 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
- Use stock SUTime rule files unless you control their attribute output
- Validate custom rule output attributes against Timex's expected keys (value, tid, type, begin, end)
- Handle downstream absence of TimexAnnotation defensively
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 sentenceView on GitHub (pinned to 1b7edd19c4)