Pith. sign in

REVIEW 3 major objections 5 minor 53 references

A Semantic Parsing Framework for End-to-End Time Normalization

T0 review · 3 major / 5 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read This paper reframes time normalization as executable SCATE code generation and shows that a 0.5B-parameter model can beat the large language models that generated its training data.

desk verdict A solid empirical paper on SCATE time normalization via code generation, with a genuinely useful executable library, but the unmeasured quality of LLM-generated training data and the missing prior-system baselines should force a major revision. read the letter →

arxiv 2507.06450 v1 pith:QL7K3DLD submitted 2025-07-08 cs.CL

Xin Su , Sungduk Yu , Phillip Howard , Steven Bethard This is my paper · ORCID
classification cs.CL
keywords timenormalizationSCATEcodegenerationdataaugmentationtemporalexpressionlargelanguagemodelsTempEval-2013
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

Time normalization—converting phrases like 'three weeks ago' into concrete dates—has usually been done through a rigid time-tagging schema that cannot express multi-span, event-relative, or compositional expressions. This paper argues that the job is better posed as code generation: an executable Python library implements the compositional SCATE semantics, and a model writes SCATE code that is run to produce normalized intervals. To get enough training data, large language models annotate 10,000 newswire sentences, and only the generated code that runs without error is kept, yielding 8,583 validated code blocks. A 0.5B-parameter model fine-tuned on this augmented data plus the original TempEval-2013 training set reaches F1 0.59 on the test set, above the 0.52 of Claude 3.7 and 0.51 of GPT-4.1 prompted in the same setup. The central promise is that expressive, interpretable time normalization can run on a single consumer GPU rather than only in large cloud APIs.

What carries the argument

The load-bearing mechanism is an executable Python implementation of the SCATE temporal semantics. Its core objects are intervals, periods, repeating intervals, and higher-order temporal operators—Last, Next, Before, After, Nth, This, These, Union and Intersection—that compose into code such as `Before(Interval.of(2024, 9, 1), Last(...), Period(WEEK, 1))`. The library makes SCATE annotations runnable, so the same code serves as a training target, as prompt documentation, and as an automatic validator: generated code that fails at runtime is discarded, and the rest is executed to obtain normalized intervals. The augmentation pipeline prompts large language models with this library documentation to annotate 10,000 CC-News sentences and keeps 8,583 code blocks that pass the runtime filter.

What would settle it

Sample a few hundred of the 8,583 generated code blocks, execute them, and compare their normalized intervals against gold-standard TempEval-2013 annotations for the same expressions; if a substantial share of the blocks that run nonetheless land on the wrong intervals, the filter is admitting semantically wrong training signal and part of the small model's edge over its LLM parent is an artifact of shared annotation bias.

Watch

Extended reading notes

Core claim

The paper's central claim is that representing temporal expressions as executable SCATE code converts time normalization into a code-generation problem with a built-in correctness check: outputs that raise runtime errors are discarded, and outputs that run yield timeline-anchored intervals by construction. The authors claim that, under this formulation, large language models can be prompted to produce SCATE code for unlabeled text, and the resulting validated code can train small local models. Their evidence comes from TempEval-2013: Qwen2.5-0.5B trained on the LLM-augmented code plus the original training set reaches 0.59 accuracy and F1, outperforming the parent LLMs Claude 3.7 (0.52) and GPT-4.1 (0.51), and beating direct interval generation by more than 10 points. They further claim that the code acts as a chain-of-thought: the model writes the reasoning, and the final interval is obtained by execution rather than by the model guessing a date.

Load-bearing premise

The paper's gains rest on the premise that LLM-generated SCATE code that executes without errors is semantically valid enough to serve as training signal, because the runtime filter checks that the code runs, not that the normalized intervals match gold labels.

Editorial extensions

If this is right

  • A 0.5B-parameter model can perform compositional, multi-span, and event-relative time normalization on consumer-grade hardware, removing the need to call large cloud APIs for every normalization.
  • SCATE code generation outperforms direct interval generation by more than 10 F1 points, indicating that an intermediate executable representation acts as an effective reasoning scaffold for temporal expressions.
  • LLM-generated code that passes a runtime check is a scalable source of training supervision, yielding 8,583 validated code blocks from 10,000 sentences without human annotation.
  • Augmented and human-annotated data are complementary: the small model trained on either alone reaches F1 0.41 or 0.01, while the combination reaches 0.59.
  • The best small model's main failure mode is missed temporal expression spans rather than malformed SCATE code, so further gains are most likely to come from improving span detection.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Because the runtime filter validates only that code executes, not that it matches a gold interval, the augmented set may contain executable-but-semantically-wrong blocks; measuring that share would show how much of the small model's gain is genuine learning rather than distillation of LLM annotation biases.
  • If executable code with automatic checking is the key ingredient, the same recipe—an executable target semantics, an LLM that proposes code, and execution as a filter—could transfer to other structured tasks with runnable outputs, such as math word problems or database queries.
  • The error analysis suggests a concrete next step: add a small span-detection component or train jointly on boundary marking and code generation, which could lift recall without altering the code-generation core.
  • The augmented text comes from the same newswire domain as the test set, so the reported F1 may not carry over to clinical, conversational, or social-media text; evaluating on such domains would test the formulation's generality.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 5 minor

Summary. The paper proposes treating time normalization as a code generation task. The authors implement the SCATE temporal framework as an executable Python library (PySCATE), use LLM prompting to annotate unlabeled CC-News sentences with SCATE code, filter the generated code by runtime execution, and fine-tune Qwen2.5-0.5B on the augmented data plus the TempEval-2013 SCATE training set. On a consolidated test set of 313 items, the fine-tuned 0.5B model achieves 0.59 F1, outperforming zero-shot prompted Claude 3.7 (0.52 F1) and GPT-4.1 (0.51 F1). The central claim is that small, locally deployable models can be trained to generate SCATE code with competitive performance using such an LLM-based augmentation pipeline.

Significance. If the augmentation pipeline is reliable, the contribution is practically useful: it provides an end-to-end, interpretable, deterministic mechanism for time normalization, and it demonstrates a concrete recipe for distilling LLM annotation ability into a small deployable model. The paper is transparent about several limitations, and it includes bootstrap confidence intervals and an error analysis, which are strengths. However, the central comparison is weakened by two gaps: the semantic validity of the 8,583 LLM-generated training examples is not measured, and no quantitative comparison is made to the existing SCATE-based systems of Laparra et al. (2018) and Xu et al. (2019). The claim that the small model 'outperforms its LLM parents' is only as strong as the unverified quality of the augmented labels, so the result is conditional on an assumption the paper does not test.

major comments (3)
  1. [§3.3, §4.2] The statement that discarding samples that produce runtime errors 'thus ensuring syntactically and semantically valid SCATE Python code' is a non sequitur. The runtime filter checks only executability; a generated SCATE expression can execute successfully and still normalize to the wrong interval (wrong year, wrong operator, wrong span, or wrong composition). Since the 8,583 CC-News blocks have no gold labels, the paper provides no estimate of the semantic accuracy of the augmented training data. Table 2 gives only indirect evidence: the model trained on CC-News alone reaches F1 0.41, below its zero-shot parent Claude 3.7 (0.52), which suggests the augmented labels carry systematic biases that the 557 gold blocks correct. The headline claim that the fine-tuned small model outperforms its LLM parents therefore rests on an unsupported assumption. I would like to see a random-sample audit of the augmented code (e.g., human or automatic comparison of the executed intervals against gold annotations on a few hundred items), with the resulting precision reported.
  2. [§2.1, §4.3] The paper motivates the work by contrasting with the only complete SCATE-based systems, Laparra et al. (2018) and Xu et al. (2019), but it never reports their performance on the same data or explains how its results compare. The claim that the proposed approach achieves 'competitive performance' is therefore not supported by any direct comparison. The authors should either evaluate those prior systems on the consolidated test set (or a compatible protocol) or report their published TempEval-2013 numbers and discuss comparability.
  3. [§4.1, Appendix D] The consolidated test set has only 313 items, and the headline gap between the fine-tuned model (0.59 F1) and the best zero-shot parent (0.52 F1) is 7 points on that small set. The bootstrap intervals in Table S2 are computed by resampling 80% of the data and do not constitute a standard paired significance test. Reporting McNemar's test on expression-level predictions (or another paired test) would strengthen the claim that the fine-tuned model truly surpasses the zero-shot LLM.
minor comments (5)
  1. [§3.2.2] The example for Intersection uses Last(Interval.of(1979, 1, 24, 6), None), but the library documentation does not define the behavior of shift=None; please clarify whether None has a documented meaning (e.g., a vague 'current' shift) and add it to the API reference.
  2. [Appendix B] The predefined Repeating table says 'Day Meteorological daytime, 06:00 until 06:00'; this appears to be a typo, since a 24-hour span beginning and ending at 06:00 is inconsistent with the usual daytime meaning. Please correct the entry.
  3. [Appendix D, Table S1] Table S1 reports Gemini 2.0 Flash accuracy as 0.65, while Table 1 reports 0.64; please reconcile the two numbers.
  4. [§4.2] The JSON example is malformed: the string begins with '["{time_text": ...' and is not valid JSON. Please correct the example so that it matches the actual 'time_text'/'scate' output format.
  5. [§6] Reproducibility would be improved by releasing the PySCATE library, the augmentation prompts, and the fine-tuning scripts; the paper currently does not state whether these artifacts will be made available.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity; the central experimental claims are benchmarked against external gold annotations.

full rationale

The paper's derivation chain is empirically grounded rather than circular. The central claim, that a 0.5B model trained on CC-News augmented data plus the TempEval SCATE training set reaches F1 0.59 and surpasses its LLM parents, is evaluated on the held-out TempEval-2013 SCATE test set (merged dev+test) by executing predicted SCATE code and comparing the resulting intervals with gold-standard intervals. This evaluation does not assume the augmented data are semantically correct; it is an external benchmark. The choice of SCATE as the representational framework is inherited from Bethard and Parker 2016, a prior published framework co-authored by one of the present authors, but this is ordinary citation of external intellectual context and is not used as a uniqueness argument or to forbid alternative frameworks. Section 3.3's claim that discarding runtime-error samples 'ensuring syntactically and semantically valid SCATE Python code' is a validity gap, since executable code can still normalize to the wrong interval, but that is a data-quality and correctness concern, not a circular reduction of the result to its inputs. No fitted parameter is renamed as a prediction, no output quantity is defined in terms of its own prediction, and no equation in the paper equates a claimed result with an input by construction. Thus there is no significant circularity.

Assumptions & free parameters 4 free parameters · 5 assumptions · 0 invented entities

The central claims rest on the correctness of the SCATE-to-Python conversion, the semantic quality of execution-filtered LLM annotations, and the domain match between CC-News and TempEval newswire. The listed hyperparameters are manual choices, not fitted scientific parameters.

free parameters (4)
  • learning_rate = 2e-5
    Reported in Section 4.2 as a training hyperparameter; no tuning procedure described.
  • training_epochs = 5
    Reported in Section 4.2; chosen by hand.
  • batch_size = 64
    Reported in Section 4.2; chosen by hand.
  • sampled_cc_news_sentences = 10000
    Section 4.2: randomly sampled 10k sentences; manual choice.
assumptions (5)
  • domain assumption The PySCATE library faithfully implements the SCATE framework's semantics.
    Section 3.2 states the library 'faithfully captures all concepts in SCATE' but no tests or formal verification are provided.
  • ad hoc to paper LLM-generated SCATE code that executes without runtime error is semantically valid training data.
    Section 3.3/4.2: filtering discards only syntactically invalid or semantically incoherent outputs; semantic correctness is not checked against gold.
  • domain assumption CC-News sentences match the newswire domain of TempEval-2013.
    Section 4.2: 'It comes from the same newswire domain as with TempEval SCATE-annotated data'.
  • domain assumption The gold SCATE annotations converted to Python code via the library are correct.
    Section 4.1: conversion of XML SCATE annotations to triplets is described without validation.
  • domain assumption Exact interval match is the appropriate evaluation criterion.
    Section 4.1: assigns 1 only for exact interval match, 0 otherwise; partial credit is not considered.

how reviews work

0 comments
Cite this review

Pith. "Pith review of A Semantic Parsing Framework for End-to-End Time Normalization." pith.science (2026). https://pith.science/paper/QL7K3DLD

@misc{pith2026250706450,
  author       = {Pith},
  title        = {Pith review of: A Semantic Parsing Framework for End-to-End Time Normalization},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/QL7K3DLD}},
  note         = {Machine review of arXiv:2507.06450}
}
read the original abstract

Time normalization is the task of converting natural language temporal expressions into machine-readable representations. It underpins many downstream applications in information retrieval, question answering, and clinical decision-making. Traditional systems based on the ISO-TimeML schema limit expressivity and struggle with complex constructs such as compositional, event-relative, and multi-span time expressions. In this work, we introduce a novel formulation of time normalization as a code generation task grounded in the SCATE framework, which defines temporal semantics through symbolic and compositional operators. We implement a fully executable SCATE Python library and demonstrate that large language models (LLMs) can generate executable SCATE code. Leveraging this capability, we develop an automatic data augmentation pipeline using LLMs to synthesize large-scale annotated data with code-level validation. Our experiments show that small, locally deployable models trained on this augmented data can achieve strong performance, outperforming even their LLM parents and enabling practical, accurate, and interpretable time normalization.

Figures

Figures reproduced from arXiv: 2507.06450 by the authors.

Figure 1
Figure 1. UNION annotation: Mondays and Fridays 3. Compositional expressions that involve multiple temporal constructs, as in “May 22, 1995 ... and the following month”, where the latter phrase is semantically dependent on the former. To overcome these limitations, Bethard and Parker [2016] propose the Semantically Compositional Annotation of Temporal Expressions (SCATE) framework. SCATE represents temporal expressions throug… view at source ↗
Figure 2
Figure 2. Overview of our approach 3.1 Task Definition Our proposed method is based on the SCATE temporal normalization framework. The fundamental principle of the SCATE framework is to represent complex temporal expressions compositionally, addressing the limitations of common temporal expression frameworks such as TimeML, which has limited expressivity. For instance, TimeML cannot represent expressions that cannot be aligne… view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

53 extracted references · 52 canonical work pages

  1. [1]

    Identify time expressions in text

    work page

  2. [2]

    1990-01-01T00:00:00

    Generate the corresponding SCATE Python code for those expressions API Reference Interval Classes Implements the SCATE interval definition. Defined by a starting point (inclusive) and an ending point (exclusive). Example: class Interval(start:datetime, end:datetime) -> Interval 13 Methods Creates an Interval from two dates in ISO 8601 format. Example: Cre...

    work page 1990

  3. [3]

    third- quarter

    Writing the corresponding SCATE code for each expression Financial and Reporting Period Time Expressions Financial reports, earnings statements, and business news often contain specialized time expressions related to fiscal periods: ExpressionContextCorrect Representation Incorrect Representation "third- quarter" Past context Before(interval=Nth(interval=...

    work page

  4. [4]

    Receiving the document creation time (DCT) and text as input

    work page

  5. [5]

    Identifying time expressions in the text

    work page

  6. [6]

    next Friday

    For relative expressions (like "next Friday", "last month"), anchor them to the DCT A collection of intervals on the timeline. This class implements the Python Iterable interface to allow iteration over a set of Interval objects

    work page

  7. [7]

    Quarter references in financial contexts:

    work page

  8. [8]

    reported

    Interpreting contextual time cues: Pay attention to verb tense ("reported", "said", "announced") which may indicate the quarter reference is to a past period Look for comparative language ("year-ago quarter", "previous quarter") which specifies relative time positioning Check for explicit fiscal year indicators ("FY2023 Q3", "third quarter of fiscal 2022")

    work page 2022

Show all 53 references
  1. [9]

    year-ago quarter

    Year-ago comparisons: Expressions like "year-ago quarter" or "same quarter last year" should use Before with a period of a year Example: Before(interval=This(interval=DCT, shift=Repeating(unit=QUARTER_YEAR, range=QUARTER_YEAR)), shift=Period(unit=YEAR, n=1))

  2. [10]

    earlier that day

    Key principles for financial time expressions: Financial quarters have specific calendar alignments (Q1: Jan-Mar, Q2: Apr-Jun, etc.) # Representing "earlier that day" # (in the context of "We met at 6:00 on 24 Jan 1979") Intersection([ Last(Interval.of(1979, 1, 24, 6), None), ...

    1979

  3. [11]

    payable",

    Future event indicators: Words and phrases that signal future events: "payable", "due", "scheduled", "will be", "upcoming" Look for modal verbs indicating future actions: "will", "shall", "is to be" ExpressionContextDCT Correct InterpretationCorrect Representation "Jan. 2" "pa...

    1989

  4. [12]

    last <Month>

    Date logic with Document Creation Time (DCT): “last <Month>” → If Month ≥ DCT.month, the reference is to that month in the previous year; otherwise it is the most recent occurrence within the current year. “next <Month>” → If Month ≤ DCT.month, the reference is to that month i...

    1998

  5. [13]

    2" likely refers to January 2, 1990, not January 2, 1989

    Month sequence reasoning: If a month mentioned is earlier in the calendar than the DCT month, and context suggests a future event, it typically refers to that month in the following year Example: If DCT is November 1989, then "Jan. 2" likely refers to January 2, 1990, not Janu...

    1989

  6. [14]

    The dividend is payable [payment date] to shareholders of record on [record date]

    Common patterns in financial announcements: Dividend/payment announcements typically include: A declaration date (usually the DCT or before) A record date (usually in the near future) A payment date (usually after the record date) Example: "The dividend is payable [payment dat...

  7. [15]

    over", "during

    Incorrect annotation patterns to avoid: Never default to This(interval=Year(digits=YEAR), ...) for dates without explicitly considering whether they refer to the current or future year 27 Don't assume months mentioned in text always refer to the current year Pay attention to t...

  8. [16]

    over the weekend

    Separate core temporal expressions from prepositions when appropriate: For expressions like "over the weekend", the core temporal expression is often just "weekend" The preposition "over" typically provides context but isn't part of the time expression itself Text Correct Expr...

  9. [17]

    over the weekend

    Examples of proper boundary detection with prepositions: Note: The preposition may affect the interpretation (e.g., "over the weekend" implies the entire weekend), but the expression itself is typically just the temporal noun phrase. Handling Vague Duration Expressions For vag...

  10. [18]

    For expressions implying a non-specific duration:

  11. [19]

    Key points about vague durations: Use n=None to indicate an unspecified quantity Prefer Next with a vague period over NextN with a specific count for naturally vague expressions Don't try to quantify inherently vague expressions with specific numbers

  12. [20]

    a few X" → Period(unit=X, n=None)

    Common vague time patterns: "a few X" → Period(unit=X, n=None) "several X" → Period(unit=X, n=None) 28 "some X" → Period(unit=X, n=None) "many X" → Period(unit=X, n=None) ISO and Standard Date Format Handling When annotating standard date formats, it's crucial to correctly ide...

    1998

  13. [21]

    1998-08-07

    ISO format dates (YYYY-MM-DD): Full date formats like "1998-08-07" should be annotated with day-level specificity, not as an entire year

    1998

  14. [22]

    08/07/1998

    Common date format variants: American format (MM/DD/YYYY): "08/07/1998" European format (DD/MM/YYYY): "07/08/1998" All should be normalized to the same SCATE representation when they refer to the same date

    1998

  15. [23]

    1998-08-07

    Metadata dates: Dates appearing in document headers, bylines, or metadata sections should be treated with the same precision they express A standalone date like "1998-08-07" in a document header still refers to that specific day

    1998

  16. [24]

    today" This(interval=DCT, shift=Repeating(unit=DAY, range=DAY))This(interval=DCT, shift=None)

    Key principle: Always preserve the temporal granularity expressed in the original time expression. Never default to a broader time range (like a year) when a more specific one (like a day) is explicitly stated. Precise Annotation of Common Deictic Time Expressions Common deict...

  17. [25]

    Day-specific expressions:

  18. [26]

    , the shift=Repeating(unit=DAY, range=DAY) indicates it refers specifically to a day-long period This preserves the precise 24-hour meaning rather than treating it as a generic

    The importance of the shift parameter: Using shift=None loses the specific temporal granularity of the expression 29 For words like "today", the shift=Repeating(unit=DAY, range=DAY) indicates it refers specifically to a day-long period This preserves the precise 24-hour meanin...

  19. [27]

    last year

    Other common deictic expressions and their correct representations: ExpressionCorrect Representation Why "last year"Last(interval=DCT, shift=Repeating(unit=YEAR, range=YEAR)) Use Repeating so that the interval aligns to Jan 1 – Jan 1 of the previous calendar year, not a rollin...

  20. [28]

    last / past N

    Calendar-Aligned “last / past N” Expressions: Whenever the intent is to include complete calendar units (year, quarter, month, week, night, weekend …), choose Repeating, not Period. Period is limited to rolling or vague durations that do not align exactly to named calendar units

  21. [29]

    Core Time Expression Extraction and Modifier Separation When identifying time expressions, it's crucial to separate core temporal references from their modifiers and determiners:

    Remember: The shift parameter in temporal operators provides crucial information about the specific calendar unit being referenced, and should never be omitted for expressions with specific granularity. Core Time Expression Extraction and Modifier Separation When identifying t...

  22. [30]

    at the end of November

    Core time expressions vs. extended phrases: 30 Full Phrase Core Time ExpressionModifiers (Not Part of Expression) "at the end of November""November" "at the end of" "today's editions" "today" "'s editions" "by early December" "December" "by early" "throughout next week""next w...

  23. [31]

    's" (possessive) usually indicate the end of the core expression Prepositions (

    Principles for identifying core time expressions: The core expression contains the essential temporal reference (day, month, year, etc.) Adjectival markers like "'s" (possessive) usually indicate the end of the core expression Prepositions ("at", "on", "by", "during") typicall...

  24. [32]

    end of year

    Special cases and exceptions: Certain temporal phrases form inseparable units: "end of year", "beginning of month" Time-specific prepositions may be included when they change meaning: "in May" vs. "by May" Possessive forms can semantically modify the time reference: "yesterday...

  25. [33]

    Correct annotation examples:

  26. [34]

    next week

    Common error patterns to avoid: Including prepositions and qualifiers with the time expression Including possessive markers and the modified nouns with the time expression Splitting compound time expressions that should remain together (e.g., "next week", "last month") Article...

  27. [35]

    Articles in time expressions:

  28. [36]

    a", "an",

    Core time expression identification: Focus on the minimal span that conveys the complete temporal meaning Articles ("a", "an", "the") typically fall outside the time expression boundary Exception: When the article is integral to the meaning (e.g., "the day before yesterday") E...

  29. [37]

    Relative time expressions with articles:

  30. [38]

    earlier",

    Comparative time expressions: "earlier", "before", "prior", "previous" → Use Before operator "later", "after", "following", "subsequent" → Use After operator "ago" → Use Last operator

  31. [40]

    The document creation time (DCT) is provided as input along with the text

  32. [41]

    Focus on identifying all time expressions in the text and writing the correct SCATE code for each

  33. [42]

    Always output in JSON format with a list of objects containing time_text and scate fields

  34. [43]

    Use the appropriate SCATE operators and classes based on the time expression semantics

  35. [44]

    now", "today

    For deictic expressions (like "now", "today", "yesterday"), use the DCT as the reference point

  36. [46]

    Time expressions in the output JSON must be ordered according to their appearance in the original text

  37. [47]

    Always consider the hierarchical nature of time expressions and their composition

  38. [48]

    Pay special attention to temporal adverbs and prepositions: Words indicating past time (previously, before, earlier, formerly, in the past, etc.) should typically use the Last operator, not This Words indicating future time (soon, later, in the future, etc.) should typically u...

  39. [49]

    previously

    Misinterpreting vague temporal adverbs: Words like "previously" or "formerly" indicate a time before the reference time, so they should be annotated with Last(interval=DCT, shift=None) rather than This(interval=DCT, shift=None)

  40. [50]

    time_text

    Confusing This vs. Last: The This operator refers to the current time interval, while Last refers to a previous time interval. For example: { "time_text": "1998", "scate": "Year(digits=1998)" }, { "time_text": "April 30, 1998", "scate": "This(interval=Year(digits=1998), shift=...

    1998

  41. [51]

    Ignoring contextual cues: Sometimes temporal expressions must be interpreted based on surrounding context in the text, not just the DCT

  42. [52]

    Incorrect time expression boundary detection: Be careful when identifying the boundaries of time expressions. Pay attention to: Time expressions that span multiple tokens (e.g., 08-07-98 0618 should be treated as a single expression) Time zone indicators that are not part of t...

  43. [53]

    08-07-98 0618

    Fragmentation of combined date-time expressions: Date and time components that appear together (e.g., "08-07-98 0618") should be treated as a single time expression, not split into separate expressions

  44. [54]

    previously

    Missing implicit time references: Some texts imply a time reference without explicitly stating it (e.g., "previously" without stating when). # Incorrect (for "previously") This(interval=Interval.of(1989, 11, 2), shift=None) # Correct (for "previously") Last(interval=Interval.o...

    1989

  45. [730]

    1990" corresponds to [1990-01-01, 1991-01-01). Repeating interval A sequence of intervals on the timeline. E.g.,

    URL https://aclanthology.org/2020.emnlp-main.730/. Lukas Lange, Jannik Strötgen, Heike Adel, and Dietrich Klakow. Multilingual normalization of temporal expressions with masked language models. In Andreas Vlachos and Isabelle Augenstein, editors, Proceedings of the 17th Confer...

    2020 arXiv

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.