A Semantic Parsing Framework for End-to-End Time Normalization
Authors: Xin Su
Sungduk Yu
Phillip Howard
Steven Bethard
Venue: NeurIPS 2025 poster ()
Keywords: Time Normalization
Temporal Information Extraction
Primary area: applications

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.

A Semantic Parsing Framework for End-to-End Time Normalization
Xin Su Intel xin. su@intel. com
Sungduk Yu Oracle sungduk, yuroracle com
Phillip Howard
Thoughtworks
phillip phillpp.oooarddtonnnennnooo hww.:hoorrottttogooorrrssoooo
Steven Bethard
University of Arizona
bethard@arizona edu
Abstract
Time normalization is the task of converting natural language temporal expressions into machine- machine-readable readable representations. It underpins many downstream applications in information retrieval, question answering, and clinical decision- maksii.. Tradi- tional 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 nor- malization as a code generation task grounded in the SCATE framework, which defines temporal semantics through symbolic and compositional operators. We implement fully executable SCATE Python library and demonstrate that large language models (LLMMs) can generate executable SCATE code. Leveraging this capability, develop an automatic data augmentation pipeline using LLMs 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 L.M parents and enabling practical, accurate, and interpretable time normalization.
Introduction
Time normalization refers to the task of converting temporal expressions in natural language into machine-readable formats. For example, the phrase "three days ago" spoken on August 25, 2024, should be normalized to 2024-08-22 22. Time normalization plays crucial role in variety of temporal reasoning applications, including literature study [Fischer and Strötgen 2015), question answering
[uu et al. 2023 event analysis (Vossen et al. 2016], and climical decision-making [in et al. 2015
Most existing time normalization systems Kim et al. 2020 Shwartz 2022 Lange al. 2023 are
based on the ISO-T S0-TimeML framework [Pustejovsky et al. 2010 These systems typically follow two-stage pipeline: first identifying temporal expressions in text, then classifying them into predefined normalized representations (e.g., mapping "noon" to a specific time of day). While effective for standard expressions, this approach fundamentally limited by the rigidity and restricted expressivity of the ISO-TimeML. schema. As pointed out by |etthrdd and Parker (2016), S50-TimeML--hasee systems cannot effectively handle several classes temporal expressions:
1. Multi-span expressions that span across calendar units, such "every Monday for the past three weeks":
Work done while Intel. Code and models are available at ahtppp///ggihho...mm/llllaaaa//a
39th Conference on Neural Information Processing Systems (NcurIPS 2025).

---

DAY-OF-
UNION
DAY-OF-WV WEEK
TYPE=MONDAY
ARPEATING-INTERVAAN and
TYPE-PRIDAY Fridays
Mondays
Mondays
Fridays
UNION
Figure 1: SCATE UNION operator example: "Mondays and Fridays" represented as the union of two repeating intervals the timeline.
2. Event-relative expressions, such "three weeks postoperative", where "three weeks" is relative to "surgery";
3. Compositional expressions that involve multiple temporal constructs, in "May 22, 1995 and the following month", where the latter phrase is semantically dependent on the former.
To overcome these limitations, |ethard and Parker (016) propose the Semantically Compositional Annotation of Temporal Expressions (SCATE) framework. SCATE represents temporal expressions through compositional and symbolic semantics using a rich set of temporal operators (e.g.. Union, Intersection, RepeatingInterval) For instance, the expression "Mondays and Fridays" " is represented as:
Union (Repeat (DayOfWeek (Type=Monday)) RepeatingInterval (DayDfWeek (Type=Friday)))
As illustrated in Figure 1. this operation produces all occurrences of Mondays and Fridays along the timeline. In this representation, both Mondays and Fridays are modeled as kepeatingInterval objects, and the conjunction and is captured using the Union operator. This compositional design allows SCATE to handle a broader range of temporal expressions and produce precisely defined, timeline-anchored intervals. Despite its expressivity, existing SCATE-based systems [Laparra et al. 2018 Xu et al. 2019] rely on complex, multi-stage pipelines. These systems treat SCATE as an annotation schema, training separate models identify its atomic concepts and then applying handcrafted rule systems to reconstruct full interpretations. This approach results in high runtime costs, reduced maintainability. and limited deployability in real-world applications.
In this work, we propose a novel, end-to-end formulation of time normalization as a code gener- executable Python
ation task. Our key insight is to implement the full SCATE framework library, where all core temporal concepts and operations are mapped to Python classes and func- tions. This enables deterministically compute their normalized time intervals.
directly generate executable SCATE code from natural language inputs and
Our main contributions are follows:
We design and implement a complete Python library that faithfully captures concepts in SCATE, making the semantics of each time expression interpretable and executable.
We construct detailed prompting strategies leverage large language models (LLMss for data augmentation, generating 10x more labeled examples than existing annotated datasets, with automatic validation through code execution.
We demonstrate that small, locally deployable models (S1B parameters) can be trained on the augmented dataset generate SCATE code with competitive performance, enabling practical deployment of expressive time normalization systems.

---

2 Related Works
2.1 Time Normalization
The vast majority of existing time normalization methods are built upon the ISO-TimeML framework.
Early systems, such HeidelTime [Strötgen and Gertz 2010) and SUTime [Chang and Manning 2012]. adopt rule-based approaches to convert recognized temporal expressions into the standardized format defined by ISO-TimeML. More recently, transformer-bast based models have been introduced for
this task. For instance, [Swwartz (2022), Lange et al. [2023), and Kim et al. [2020) train transformer- based classification models to map identified temporal expressions to predefined normalized time categories. In contrast, Laparra et al. (2018) and Xu et al. [2019) present the only complete time normalization pipeline grounded the SCATE framework. Their approach involves using neural models, such as LSTMs, for temporal expression recognition, followed by a rule-based component to link these expressions to their final normalized forms. Distinct from all prior work, our method introduces simple and practical end-to-end solution for time normalization formulated as code generation task. By generating executable Python code, our approach directly maps textual temporal expressions to their normalized representations, offering seamless and interpretable mechanism.
2.2 Information Extraction via Code Generation
Another related line of work gaining much recent attention is the representation of information extraction (IE) tasks using programming code or code-like structures. Instead of producing free-form text sequences of labels, these approaches explicitly represent extracted information structured code. This paradigm is particularly appealing in the era of powerful pretrained L.Mss, which can effectively translate implicit semantic structures into explicit code-like or structured formats.
Recent studies demonstrated that code-based prompting allows efficient capturing of structured information. Code4Struct [Wang al. 2022] and CodelE (Li et al.
2023 framed IE tasks explicitly as code generation problems, showing that code-specialized LLMs outperform natural- lanuuae-language LLMs in few-shot settings for IE tasks such as named entity recognition (NER) and relation extraction (RE). Expanding this further, Code4UIE [Guo et al. 2024) introduced eetrieval-augment code prompting, retrieving relevant few-shot examples, along with their universal IE approach.
An alternative inference-time strategy by Geng et al. (2023) adapted grammar-constraine decoding, explicitly enforcing output schema via formal grammars, thus achieving competitive IE performance without any model fine-tuning.
Complementing inference-time methods, another approach focuses on training specialized IE models. Doc2Dict [Towssedd et al. [202T] directly trained a generative T5 model produce structured JSON outputs from documents, eliminating intermediate annotation steps unlike traditional pipeline-basee based models. More recently, KnowCoder (Li et al. 2024) proposed a dedicated IE LLM, undergoing a two- phase training (schema-based code pretraining and aahema--uided instruction tuning). significantly outperforming general-purpose I.I.Ms. In subsequent work, KnowCoder-X X (Zuo et al.. (2025) further extended this framework to multilingual IE tasks through cross-lingual alignment training, achieving state-of-the-arn multilingual IE performance.
3 Methodology
Overview In this paper, we focus on the task of identifying temporal expressions from given text and parsing them into the corresponding SCATE framework code. By deterministically executing the parsed structured code, we obtain time intervals anchored to a timeline. To accomplish this task, we first implement the concepts and operations defined in SCATE as fully executable Python objects packaged as Python library, converting existing SCATE annotations into corresponding code representations. We then leverage our Python package to construct language model prompts for large-scale annotation of unlabeled text, generating additional annotations with quality-enhancing filtering mechanisms. Finally, we train small-scale language models on both the converted data and the additional L.L.-nnntttted data for end-to-end time normalization code generation. We present an overview of our method in Figure 2
3

---

Pipeline
SCATE Annotation
Augmented Dataset
Framework
Python Implementation
Basic Concept
Finetuned SCATE Generator
Definition
LLM
Small LM
Operator Definition
Data Conversion
SCATE Prompt
PySCATE
(Text, Time Express on, code)
Example
Before
Document Time: Sep 1, 2024
Last |
Interval. of (2024, 9, 11,
week before last Tuessay
Repeating (DAY, WEEK, 11,
Period (NEEK,
Exe Execution Result: 12024-08-20, 2024-08-21)
Overview of our approach. Top: model. Bottom: Example of converting "a week before last Tuesday" into executable SCATE code with normalized output.
Figure 2:
System pipeline from Python implementation to fine-tuned
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 TimeML., which has limited expressivity. For instance, TimeML. cannot represent expressions that cannot be aligned to a single calendar unit, such "the past three summers."
The SCATE framework defines five key temporal concepts: Timeline: An infinite sequence of time points to which temporal expressions (or events) be anchored. Each time point is assumed to have second-level precision, e.g., 2015-08-03 09:35:47 represents point the timeline.
Interval: segment that can be precisely anchored to the timeline, defined by a starting point (inclusive) and an ending point (exclusive). For example, "1990" corresponds to 1990-01-01 00:00:00, 1991-01-01 00:00:00).
Repeating interval: sequence intervals on the timeline. For example, "Friday" refers to every Friday each week, representing a sequence of intervals that repeats infinitely.
Period: An amount of time expressed counts of standard time units. Periods are in- dependent of the timeline. For example, "10 weeks" does not have specific start or end points.
Temporal operator: A higher-order function that operates over periods, intervals, and repeating intervals to produce new temporal expressions. For example, the expression "Saturdays March" involves repeating "ntarvals-"aaturdyss"" and "Mareei--oombied via an INTERSECTION operator. The result is a set of Saturday intervals occurring within the month of March, which then be anchored the timeline. For formal operator definitions, we refer the reader to the original SCATE paper [Bethard and Parker 2016).
In our work, we implement all SCATE temporal constructs as composable and executable Python objects. Formally, given text T' containing n time expressions (timexi,... timex,)), ), our goal is to

---

train a parameterized model M that maps T to corresponding set of SCATE code representations (code)..... code, such that:
Execute(code:) - Interval; for i 1,...,
where each Interval, is normalized, Lineline-anchorel temporal interval.
This formulation enables the task to be approached structured code generation problem, with model outputs grounded in formally defined temporal logic system.
3.2
SCATE Code Representation
3.2.1
Base Class Definitions
To faithfully represent the SCATE framework's temporal concepts, we implement comprehensive object-oriented Python library. Our implementation centers around several base classes that directly correspond to SCATE's fundamental concepts. Our design adheres to two core principles: compo- sitionality and executability. The compositional nature allows classes to be flexibly combined to represent complex temporal expressions, mirroring how most natural language constructs temporal references. Meanwhile, the executability principle ensures each object can be deterministically executed to produce concrete intervals on the timeline, with classes implementing necessary addition and subtraction methods for direct interaction with Python datetime objects.
Interval Class. The Interval class serves as the cornerstone of our implementation, directly embody- ing SCATE's interval concept. It represents specific time span the timeline with well-defined start and end points. Intervals can created through various constructors, such as Interval. of (1990) to represent the year 1990, Interval of (1990, 1, 1) for more specific dates like January 1, 1990, or using standard ISO format through Interval. fromisof ormat 0 ("1000001-1111000000000000000000 1994-01-01 01:00010010000000000000000000000 :0:
Unit Class. We implement Python enumeration represent standard time units (e.g., SECOND, MINUTE, HOUR, DAY, WEEK, MONTH, YEAR, CENTURY), These units serve as building blocks for periods and provide utilities for truncating dates and calculating relative deltas.
Shift Class. We introduce the Shift class as an abstract base class that captures the concept of movement along the timeline. The Shift class defines the interface for objects that can be added to or subtracted from time points to yield intervals, serving as the foundation for both SCATE's periods and repeating intervals.
Period Class. The Period class implements SCATE's period concept, encapsulating an amount of time expressed as counts of standard time units defined through the Unit class. For instance, "three months" represented as Period (MONTH, 3). Periods can be combined through the PeriodSum class to express complex durations like "two years and day" PeriodSum (Period (YEAR, 2). Period (DAY, 1)]).
The Repeating class implements SCATE's repeating interval concept to capture calendar-anchored recurring time intervals. For example, "February" (all Februaries across the timeline) is represented as Repeating (MONTH, YEAR, value=2), while "Thursday" would be Repeating (DAY, WEEK, value=3) (where we follow the dateutil library in using value=0 to represent Monday). We also extend the Repeating class to implement common temporal concepts as specialized classes, such as Spring, Summer, Fall, Winter for seasons, and Morning, Noon, Afternoon, Evening, Night for parts of the day.
Repeating Class.
3.2.2 Temporal Operators Class Definitions
distinctive feature of SCATE is rich set temporal operators. We implement these operators through a series of Python classes.
5

---

Positional Operator Classes. We implement a group of positional operators primarily used to move intervals relative reference points. Two key operator pairs are Last/Next and Before/After. The Last and Next classes respectively find the closest intervals before or after given Shift, while Before and After move intervals backward or forward by specific time units or occurrences. For example, "the previous summer" when spoken on February 14, 1912 can be represented as Last (Interval. of (1912, 2, 14), Summer ()), while "three Aprils after" written on January 23, 1993 can be expressed as After (Interval of (1993, 1, 23), Repeating (MONTH, YEAR, value=4), n=3). These seemingly similar but functionally distinct operators enable us to accurately capture different types of temporal expressions in natural language.
Selection Operator Classes. Selection operators primarily select specific instances from time sequences. The Nth class allows selection of the n-th shift from the beginning or end of an interval, while the This class finds the current shift containing given interval. These operators apply to ordinal expressions (c.g.. "the third Thursday") and deictic expressions (c.g.. "this month"). For example, "third-to-last Sunday of 2024" can be represented as Nth (Year (2024), Repeating (DAY, WEEK, value=6), index=3, from_ cod__end-rree while "this January" spoken November 10, 1037 can be expressed as This (Interval. of (1037, 11, 10), Repeating (MONTH, YEAR, value=1)).
Range Operator Classes. Range operators handle relationships between multiple intervals. The Between class creates span between two intervals, while the Intersection class finds the overlap among multiple intervals. These operators are particularly useful for handling time ranges and intersections of multiple temporal constraints. For example, "since 1994" writ- ten on January 9, 2007 can be represented as Between (1994), Interval. of (2007, 1, 9)), while "earlier that day" in the context of "We met at 6:00 on January 24, 1979. Earlier that day..." would be interpreted as Intersection ( [[ast (Interval. of (1979, 1, 24, 6), None), Interval. of (1979, 1, 24)]).
Collection Operator Classes. We implement multiple collection operators to handle sets of in- tervals, such These, LastN, and NextN. These operators extend the functionality of basic op- erators, allowing us to process multiple related intervals. For example, "the next six Fridays" when written on December 22, 1714 be represented as NextN (Interval... of (1714, 12, 22), Repeating (DAY, WEEK, value=4), n=6), while "Tuesdays in January 2025" can be expressed These (Interval. of (2025, 1), Repeating (DAY, WEEK, value=1))).
Union and Intersection Classes. We implement ShiftUnion and RepeatingInterssction classes that allow combine multiple shifts find intersections of repeating intervals. For example, "Mondays and Fridays" can be represented as ShiftUnion ( [Repeating (DAY, WEEK, value=0), Repeating (DAY, WEEK, value=4)]), while "Saturdays in March" can be expressed as depeatingIIterreettao ([Repeating (DAY, WEEK, value=5), Repeating (MONTH, YEAR, value=3)]).
3.3 Data Augmentation
The expressive power and flexible design of SCATE introduces potential challenge: the scarcity of large-scale annotated data. Under the original SCATE annotation framework, human annotators must identify all temporal expressions in text and their corresponding operators, as illustrated in Figure []] This precise annotation requires domain experts; otherwise, annotation quality may be insufficient for model training. For instance, (Su et al. [022] report that even when two PhD students from related fields spent approximately 10 days on annotations, those annotations ultimately degraded model performance in temporal expression recognition due to lack of annotator training the complex SCATE annotation guidelines.
Given our complete Python implementation of SCATE, natural question arises: since LLMs like Claude 3.7 (Anthropic 2025 and GPT-4.1 (OpenAl 2025) have demonstrated unprecedented code generation capabilities, could we leverage them to identify temporal expressions in unlabeled text and generate corresponding SCATE Python code at scale? This would yield (text, time expression, python code) triplets for training smaller, more deployable language models.

---

To this end, we construct detailed LLM prompts (SCATE prompt) for data augmentation. We present our data augmentation prompts in markdown format, with an example shown in the Appendix These prompts effectively serve as formal documentation for our Python library, thoroughly introducing SCATE's key temporal concepts, defining each implemented class, detailing possible usage patterms, and providing examples to clarify potential confusion points (e.g., distinguishing between Next and After operators). Our objective is to fully leverage LLMs' code generation capabilities a code-generation framework, adapting them to generate code for Python libraries they may not have encountered during pre-training. We iteratively develop these prompts through experimentation on the training set, refining the SCATE operator descriptions and examples to maximize LLM code generation quality.
An immediate post-gent sestteeerrttion constraint enforcement method emerges from our use of well-defined Python code objects as targets: we simply execute the generated SCATE Python code and discard samples that produce runtime errors, thus ensuring syntactically and semantically valid SCATE Python code.
4 Experiments
4.1 Datasets
TempEval-2013 [UzZaman al. 2013] data has been annotated with publicly available SCATE annotations, including training, development, and test sets. Using our implemented SCATE Python library, we convert the original XML-formatted SCATE annotations into (sentence, time expression, SCATE code) triplets. The objective is to identify all potential time expressions in input sentences and represent them using SCATE code. To obtain larger test set for evaluating the generalization capability of our proposed method, we merge the original development and test sets into a consolidated test set for final model performance evaluation. The resulting dataset includes 557 annotated SCATE code block in the training set and 313 in the test set. We use the training set to refine prompts and select the optimal LLM for data augmentation.
Evaluation Metries Our evaluation is based on gold-standard triplets, where each triplet consists of (sentence, time expression span, SCATE code). For each triplet, we assess the time expression by first determining whether it was successfully identified. If time expression remains undetected, its normalization accuracy is assigned value of 0. For identified expressions, we execute the predicted SCATE code to generate normalized time intervals and compare them with the gold-standard intervals. We assign accuracy of for exact matches and 0 otherwise. Based on this approach, we calculate standard evaluation metrics including average execution accuracy, precision, recall, and Fl score.
4.2 Implementation Details
Models and Hyperparameters We access various LLMs through cloud-based APIs: GPT-4.1 via Azure OpenAl, Claude 3.7 via Amazon Bedrock, and Gemini [Gogll DeepMind 2025b via Google Cloud Platform. For local model training, we train both Qwen/Qwen2.5
Instruct [Tam 2024] and Ta-Large [Raffel et al., 2020] on single NVIDIA 80GB A100 GPU with 5 epochs and batch size 64. The learning rates are 2 x 10-5 for Qwen and 5 x 10 for TS. We prompt or train models to generate JSON strings where each item represents a time expression and SCATE code pair, for example: ["[time_text)) "scate": "Last (interval=Interval (1998, 2, 13), (unit-- n=None))}"
"recent years",
Data Augmentation Text We randomly sample 10k sentences from the CC-News Mackenzie al. 2020) dataset- -widely used in large language model pretraining as our source for data augmentation. comes from the same newswire domain as with TempEval SCATE-annotated data. We then apply Claude 3.7 to these sentences using our designed SCATE prompt to generate temporal annotations. After prompt-based generation, we apply runtime filtering step to discard syntactically invalid or semantically incoherent outputs. This process yields a total of 8 8,583 valid SCATE code blocks.
7

---

Table 1: Performance of LLMs on Temporal Expression Recognition and SCATE Code Generation on Training Set (557 examples).
Model
Accuracy
Precision
Recall
F1
Claude
0.62
0.64
0.62
0.63
Claude 3.7
0.69
0.63
0.69
0.66
Gemini 2.0 Flash
0.64
0.64
0.64
0.64
Gemini 2.5 Flash
0.61
0.63
0.61
0.62
Gemini 2.5 Pro
0.50
0.64
0.50
0.56
GPT-4.1
0.67
0.60
0.67
0,63
Average
0.62
0.63
0.62
0.62
Table 2: Performance comparison of different methods on the (313 examples).
Methods
Accuracy
Precision
Recall
F1
Qwen2.5-0.5B + Training Set
0.01
1.00
0.01
0.01
Qwen2.5-0.5B CC-News
0.37
0.46
0.37
0.41
Qwen2.5-0.5B + CC-News Training Set
0.59
0.59
0.59
0.59
T5-Large + CC-News Training Set
0.37
0.52
0.37
0.43
Claude 3.7 + SCATE Prompt
0.49
0.56
0.49
0.52
Claude 3.7 + Interval Few-shot Prompt
0.38
0.38
0.38
0.38
GPT 4.1 + SCATE Prompt
0.51
0.51
0.51
0.51
4.3
Main Results
Can LLMs identify time expressions and parse corresponding SCATE code? To answer this question and identify the optimal state-of-the-an model for our designed data augmentation, we test the most popular large language models on the training set, including Claude 3.5 Haiku, Claude 3.7 Sonnet, Gemini 2.0 Flash, Gemini 2.5 Flash, Gemini 2.5 Pro, and GPT 4.1. We prompt these models using the approach described Section 3.3 to identify temporal expressions and generate corresponding SCATE code. The results are presented in Table These state-of-the-art models achieve an average accuracy and Fl score of 0.62, indicating that while large models can generate SCATE code through prompting to reasonable degree, there remains significant room for improvement. Among the evaluated models, Claude 3.7 demonstrates the best performance.
Is targeting SCATE code better than directly generating time intervals? One of our key hypothe- ses for time normalization is that existing LLMs can more effectively generate code representations of temporal operations than implicitly perform these operations directly identify time expressions and their corresponding intervals. Similar to recent work (Wei et al. 2022) finding that generating chain-of-thouge reasoning before providing answers significantly improves performance in mathe- matical reasoning, we posit that SCATE code acts as a form of chain-of coai--of-thon of-thought, with the additional benefit that we need not rely on the model produce the final answer since we can determine this through code execution.
To validate this hypothesis, we employ conventional few-shot prompting (Interval Few-shot Prompt) to direct Claude 3.7 in identifying temporal expressions and their corresponding time intervals in input text (the specific Interval Few-shot Prompt is provided Appendix C). We contrast this with prompting Claude 3.7 to generate SCATE code using our approach described in Section 3.3. As shown Table 2 the SCATE code generation approach significantly outperforms direct time interval generation, surpassing it by more than 10 points in both average accuracy and F1 scores.
Can we train a smaller local model for SCATE generation? Temporal normalization typically functions one component within larger data processing retrieval pipelines. Consequently, there a clear need for efficient solutions with low computational costs. Relying entirely on large models like Claude 3.7 presents challenges for scaling temporal normalization deployments. Therefore,

---

smaller model (< IB parameters) capable of inference on a single consumer- -gradeer-rgdddeeee GPU better aligns
with practical requirements.
We explore this possibility by fine-tuning Qwen2.5-0.5B on three different data combinations: on the original TempEval 2013 training set (Training Set), on data augmentation-labeled data (CC-News), and on a combination of both (CC-News + Training Set). We observe that small models struggle to achieve reasonable performance on limited datasets, even with manually annotated training data from TempEval, with average accuracy and Fl scores approaching zero. Fine-tuning on augmentation- labeled data shows notable improvement, though still maintaining a considerable gap compared its parent data augmentation method (Claude 3.7 + SCATE Prompt).
However, when combine our augmented data with the original training set, we observe significant performance improvements, achieving 0.59 average accuracy on the test set Surpsuaass its parent data augmentation method (Claude 3.7 SCATE Prompt) by 10 points. This demonstrates the complementary nature of augmented and original training data, and confirms that smaller, deployable models can effectively perform temporal normalization when provided with sufficient and diverse training examples.
How efficient is our method compared to existing systems? Beyond accuracy improvements, our method offers significant computational advantages. On the test set, our fine-tuned Qwen2.5-0.55
model achieves 31.7x faster inference than the previous LSTM-based system (Xu et al. 2019]. processing the entire test set in 6 seconds compared to 190 seconds. Additional comparisons and statistical significance analysis with 95% confidence intervals are provided in Appendix D
How do encoder-decoder models compare to decoder-only architectures? To validate our choice of decoder-only architecture, we also fine-tune T5-Large, a representative encoder-decoder model tasks. As shown in Table T5-Large achieves an F1 score of 0.43, comparable to our Qwen2.5-0.5D decoder-only model trained only on CC-News (FI: 0.41) but significantly lower than the full Qwen model (FI: 0.59). This demonstrates that decoder-only architectures are better suited for our SCATE code generation formulation, with Qwen2.5-0.5B achieving superior performance despite having fewer parameters (500M vs. 770M).
widely used for requence-to-sequeee
What are the main errors in the best-performing fine-tuned model? We conducted an error analysis on 20 errors from the Qwen2.5-0.55 + CC-News + Training Set model. The analysis reveals that the most common issue is missed temporal expressions (70%), where the system fails identify time phrases annotated in the gold annotations. The second most frequent problem is boundary errors (10%), where the system's identified temporal expression has boundary differences from the gold standard, despite the SCATE expression being logically similar. For example, the gold standard might annotate "year," while the system identifies "within a year."
Some errors (10%) are structural, such as in "third-quarter net loss.. year-earlier," which involves nested temporal comparisons (using Before(Nth(...)) structure), but the system only captures individ- ual fragments rather than the complete structure. SCATE type errors (5%) manifest as inappropriate operator selection, such as labeling "later" as Next(...) instead of the more semantically appropriate After(...). Granularity errors (5%) occur when the system represents specific expressions with coarser time units, such as simplifying "1 11/02//89" to Year( (199) instead of preserving the month and day information.
Overall, the primary challenges lie not in the model's 's ability to generate SCATE code but in span recognition-a traditional NLP task. Improving the model's identification of temporal expression spans represents a promising research direction for enhancing overall performance, or alternatively, introducing an additional small classification model specifically for span identification.
5 Limitations
We focus on TempEval-200 2013, the only publicly available dataset with full SCATE annotations, as the primary benchmark for evaluation. While this dataset provides high-quality supervision, does not fully capture the diversity of temporal expressions found in open-domain or multilingual scenarios. Our model fine-tuning experiments are limited to a single small-scale open-source model (Qwen2.5-0.5BB, without exploring alternative architectures or larger models. Additionally, our data

---

augmentation pipeline relies on a subset of proprietary LLMs, and we do not systematically compare across the full range of commercial or open-source source models.
6 Conclusion
We present a new end-to-end approach for time normalization by framing it as a code generation problem based on the SCATE framework. Our method unifies symbolic temporal semantics with executable representations, enabling deterministic and interpretable normalization of complex time expressions. Through comprehensive Python implementation and carefully designed prompting strategies, we show that LLMs can effectively identify temporal expressions and generate high-quality SCATE code. More importantly, we demonstrate that tine-tuning small models on combination of LLM-augmented and annman-annttated data achieves strong performance while remaining deployable on standard hardware. Our findings suggest that compositional code generation offers a scalable and semantically grounded solution for time normalization.
References
Anthropic. Claude 3.7 sonnet and claude code. 3-7-de-e--- Feb 2025. Accessed: 2025-05-16.
Steven Bethard and Jonathan Parker. A semantically compositional annotation scheme for time normalization. In Nicoletta Calzolari, Khalid Choukri, Thierry Declerck. Sara Goggi. Marko Gro- belnik, Bente Maegaard, Joseph Mariani, Helene Mazo, Asuncion Moreno, Jan Odijk, and Stelios Piperidis, editors, Proceedings of the Tenth International Conference on Language Resources and Evaluation (LRECC 16), pages 3779-3786 Portorož, Slovenia, May 2016. European Language 1599/
Resources Association (ELRA). URL
Angel X. Chang and Christopher Manning. SUTime: A library for recognizing and normaliz- ing time expressions. In Nicoletta Calzolari, Khalid Choukri, Thierry Declerck, Mehmet Ugur Dogan, Bente Maegaard, Joseph Mariani, Asuncion Moreno, Jan Odijk, and Stelios Piperidis, editors, Proceedings of the Highth International Conference on Language Resources and Evalua- tion (LREC'12), pages 3735-3740, Istanbul, Turkey, May 2012. European Language Resources Association (ELRA). URL httph: http::ttt///aalii/e ptttps://aclannhoologg. wttp:aattwwoogoooorr/-----1111 org/L12-1122//
Frank Fischer and Jannik Strötgen. When does (german) literature take place? on the analysis of temporal expressions in large corpora. In Proceedings of DH 2015: Annual Conference of the Alliance of Digital Humanities Organizations, volume 6, 2015.
Saibo Geng, Martin Josifoski, Maxime Peyrard, and Robert West. Grammar--onstrained decoding for structured nlp tasks without finetuning, arXiv preprint 23X1, 2023.
Google DeepMind. Gemini pro. May 2025a. Accessed: 2025-05-16.
Google DeepMind. Gemini flash. httpps///eepmmindgggggglg/eeeeee Apr 2025b. Accessed: 2025-05-16.
Yucan Guo, Zixuan Li, Xiaolong Jin, Yantao Liu, Yutao Zeng, Wenxuan Liu, Xiang Li, Pan Yang, Long Bai, Jiafeng Guo, et al. Retrieval- code generation for universal information extraction. In CCF International Conference on Natural Language Processing and Chinese Computing, pages 30-42. Springer, 2024.
Allen Kim, Charuta Pethe, and Steve Skiena. What time is it? temporal analysis of novels. In Bonnie Webber, Trevor Cohn, Yulan He, and Yang Liu, editors, Proceedings of the 2020 Conference on Empirical Methods in Natural Language Processing (EMNLP), pages 9076-9086, Online, November 2020. Association for Computational Linguistics. doi: 10. 112116///11/200.emmpp..... 730. URL
.ogg/y.org/oo 2020. emnlp-main. 730/
Woosuk Kwon, Zhuohan Li, Siyuan Zhuang, Ying Sheng, Lianmin Zheng, Cody Hao Yu, Joseph Gonzalez, Hao Zhang, and lon Stoica. Efficient memory management for large language model serving with pagedattention. In Proceedings of the ACM SIGOPS 29th Symposium on Operating Systems Principles, 2023.
10

---

temporal expressions with masked language models. In Andreas Vlachos and Isabelle Augenstein. editors, Proceedings of the 17th Conference of the European Chapter of the Association for Computational Linguistics, pages 1174-1186, Dubrovnik, Croatia, May 2023. Association for http://ee2022/eeeeee. Lukas Lange, Jannik Strötgen, Heike Adel, and Dietrich Klakow. Multilingual normalization of
Computational Linguistics. doi: 10. org/2023. eacl maii.. meain.84// 84/
URL https: /ttps//////llaaoooooooooo
Egoitz Laparra, Dongfang Xu, and Steven Bethard. From characters to time intervals: New paradigms for evaluation and neural parsing of time normalizations. Transactions of the Association for Computational Linguistics, 6:343-355 356, 2018. doi: 10.1162/tacl a a0025. URL https:/7
Sallanhhology.rr//Q115
Peng Li, Tianxiang Sun, Qiong Tang, Hang Yan, Yuanbin Wu, Xuanjing Huang, and Xipeng Qiu. Codeie: Large code generation models are better few-shot information extractors. arXiv preprint arXiv:2305.05771, 2023.
Zixuan Li, Yutao Zeng, Yuxin Zuo. Weicheng Ren, Wenxuan Liu, Miao Su, Yucan Guo, Yantao Liu, Xiang Li, Zhilei Hu, et Knowcoder: Coding structured knowledge into Ilms for universal information extraction. arXiv preprint arXiv:2403.07969, 2024.
Chen Lin, Elizabeth W Karlson, Dmitriy Dligach, Monica P Ramirez, Timothy A Miller, Huan Mo, Natalie S Braggs, Andrew Cagan, Vivian Gainer, Joshua C Denny, et al. Automatic identification of methotrexate-induued liver toxieity in patients with rheumatoid arthritis from the electronic medical record. Journal of the American Medical Informatics Association, 22(e1):e151-e11 2015.
Joel Mackenzie, Rodger Benham, Matthias Petri, Johanne R Trippas, J Shane Culpepper, and Alistair Moffat. Cc-news-en: A large english news corpus. In Proceedings of the 29th ACM international conference on information & knowledge management, pages 3077-3084, 2020.
OpenAl. Introducing gpt-4.1 1 in the api. Accessed: 2025-05-16.
Boaoddxxgptt---00 gpt-4-1/ 1/
Apr 2025.
James Pustejovsky, Kiyong Lee, Harry Bunt, and Laurent Romary. ISO-TimeML: An international standard for semantic annotation. In Nicoletta Calzolari, Khalid Choukri, Bente Maegaard, Joseph Mariani, Jan Odijk, Stelios Piperidis, Mike Rosner, and Daniel Tapias, editors, Proceedings of the Seventh International Conference on Language Resources and Evaluation (LREC' 10). Valletta, Malta, May 2010. European Language Resources Association (ELRA). URL https //aclattollogyorrg 0r011001077/
Colin Raffel, Noam Shazeer, Adam Roberts, Katherine Lee, Sharan Narang, Michael Matena, Yanqi Zhou, Wei Li, and Peter Liu. Exploring the limits of transfer learning with a unified text-to-text transformer. The Journal of Machine Learning Research, 21(1):5485-555. 2020.
Vered Shwartz. Good night at 4 pm?! time expressions in different cultures. In Smaranda Muresan, Preslav Nakov, and Aline Villavicencio, editors, Findings of the Association for Computational Linguistics: ACL. 2022, pages 2842-2853, Dublin, Ireland, May 2022. Asso- ciation for Computational Linguisties. doi: 10. http://///2222..nnnss..... //aclanthology crrpollogoorg//ooooooo 2022. findings-acl. 224/
URL https
Jannik Strötgen and Michael Gertz. HeidelTime: High quality rule-based extraction and normalization of temporal expressions. In Katrin Erk and Carlo Strapparava, editors, Proceedings of the 5th International Workshop on Semantic Evaluation, pages 321-324, Uppsala, Sweden, July 2010. Association for Computational Linguistics. /ttL/ttts///acaaatiooo
htt///alaanttt http///aclaatthoogyyy www.thoooooorg//10oo...o...
Xin Su, Yiyun Zhao, and Steven Bethard. The University of Arizona at SemEval-2021 task 10: Applying self-training, active learning and data augmentation to source-free domain adaptation. In Alexis Palmer, Nathan Schneider, Natalie Schluter, Guy Emerson, Aurelie Herbelot, and Xiaodan Zhu, editors, Proceedings of the 15th International Workshop Semantic Evaluation (SemEval- Online, August 2021. Association for Computational Linguistics. doi: 10.18653/v 1.02.ss 1.56. URL ttattp:://acllanthlolgg. wwwp/////22. www.val-
202/), pages
11

---

Xin Su, Phillip Howard, Nagib Hakim, and Steven Bethard. Fusing temporal graphs into trans- formers for time-sensitive question answering. In Houda Bouamor, Juan Pino, and Kalika Bali, editors, Findings of the Association for Computational Linguistics: EMNLP 2023, pages 948-966, Singapore, December 2023. Association for Computational Linguistics. doi: 10. 1161886111222... http:/loooyyogg///// findings-emnlp 67/
findings-emnlp.67. URL BtRLtttts:///ccaaaae
Qwen Team. Qwen2.5: A party of foundation models, September 2024. URL https::tttt:::: //enll github. hotblooggwwen..5555.
Benjamin Townsend, Eamon Ito-Fisher, Lily Zhang, and Madison May. Doc2dict: Information extraction text generation. arXiv preprini arXiv:2105.075100 2021.
Naushad UzZaman, Hector Llorens, Leon Derczynski, James Allen, Mare Verhagen, and James Pustejovsky. SemEval-2013 task 1: TempEval-3: Evaluating time expressions, events, and temporal relations. In Suresh Manandhar and Deniz Yuret, editors, Second Joint Conference on Lexical and Computational Semantics ( (*SEM). Volume 2: Proceedings of the Seventh International Workshop on Semuntic Evaluation (SemEval 2013), pages 1-9, Atlanta, Georgia, USA, June 2013. Association for Computational Linguistics. URL. htt.:ttts::... http://///aaaaaholooooo/o /tg/
Piek Vossen, Rodrigo Agerri, Itziar Aldabe, Agata Cybulska, Marieke van Erp, Antske Fokkens, Egoitz Laparra, Anne-Lyse Minard, Alessio Palmero Aprosio, German Rigau, et al. Newsreader: Using knowledge resources in cross--inguall reading machine to generate more knowledge from massive streams of news. Knowledge-Badd Based Systems, 110:60-85, 2016.
Xingyao Wang, Sha Li, and Heng Ji. Code4struct: Code generation for few-shot structured prediction from natural language. arXiv preprint arXiv:2210. 128/0, 2022.
Jason Wei, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Fei Xia, Ed Chi, Quoc V Le, Denny Zhou, et al. Chain-of-thoughee prompting elicits reasoning in large language models. Advances in neural information processing systems, 35:24824 24837, 2022.
Dongfang Xu, Egoitz Laparra, and Steven Bethard. Pre-trained contextualized character embeddings lead to major improvements in time normalization: detailed analysis. In Rada Mihalcea, Ekaterina Shutova, Lun- Wei Ku, Kilian Evang, and Soujanya Poria, editors, Proceedings of the Eighth Joint Conference on Lexical and Computational Semantics ( (*SEM 2019), pages 68-74, Minneapolis, Minnesota, June 2019. Association for Computational Linguistics. doi: 10. 10.186533v1SS19-1000 URL http:ttss//ccaaahhllleee
org Sttg/S19-1005
Yuxin Zuo, Wenxuan Jiang, Wenxuan Liu, Zixuan Li, Long Bai, Hanbin Wang, Yutao Zeng, Xiaolong Jin, Jiafeng Guo, and Xueqi Cheng. Knowcoder-x: Boosting multilingual information extraction via code, 2025. URL URLhhttp... httpp://aarxv..or//aaaa
04794
12

---

NeurIPS Paper Checklist
1. Claims
Question: Do the main claims made in the abstract and introduction accurately reflect the paper's contributions and scope?
Answer: [Yes]
Justification: We confirm the main claims made in the abstract and introduction accurately reflect our paper's contributions and scope.
Guidelines:
The answer NA means that the abstract and introduction do not include the claims made the paper.
The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A No or
NA answer to this question will not be perceived well by the reviewers.
The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.
is fine to include aspirational goals as motivation as long as is clear that these goals not attained by the paper.
2. Limitations
Question: Does the paper discuss the limitations the work performed by the authors?
Answer: [Yes]
Justification: Section
Guidelines:
The answer NA means that the paper has no limitation while the answer No means that the paper has limitations, but those are not discussed in the paper.
The authors are encouraged to create a separate "Limitations" section their paper.
The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g.. independence assumptions, noiseless settings, model sell-specification, asymptotic approximations only holding locally). The authors should reflect how these assumptions might be violated in practice and what the implications would be.
The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on few datasets or with few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.
The authors should reflect on the factors that influence the performance of the approach. For example, facial recognition algorithm may perform poorly when image resolution is low images are taken in low lighting. Or speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.
The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.
If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.
While the authors might fear that complete honesty about limitations might used by reviewers as grounds for rejection, worse outcome might be that reviewers discover limitations that aren't 't acknowledged judgment and recognize that individual actions in favor of transparency play impor- tant role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.
the paper. The authors should use their best
3. Theory assumptions and proofs
Question: For each theoretical result, does the paper provide the full set of assumptions and complete (and correct) proof?
Answer: [NA]
13

---

Justification:
Our paper does not include theoretical results.
Guidelines:
The answer NA means that the paper does not include theoretical results.
All the theorems, formulas, and proofs in the paper should be numbered and cross- referenced.
All assumptions should be clearly stated referenced in the statement of any theorems.
The proofs can either appear in the main paper or the supplemental material, but they appear in the supplemental material, the authors are encouraged to provide short proof sketch provide intuition.
Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.
Theorems and Lemmas that the proof relies upon should be properly referenced.
4. Experimental result reproducibility
Question: Does the paper fully disclose all the information needed to reproduce the main ex- perimental results of the paper to the extent that affects the main claims and/or conclusions of the paper (regardless whether the code and data are provided or not)?
Answer: [Yes]
Justification: Section 4
Guidelines:
The answer NA means that the paper does not include experiments.
If the paper includes experiments, a No answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.
If the contribution is dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.
Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g.. in the case of large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.
While NeurIPS does not require releasing code, the conference does require all submis- sions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example
(a) the contribution is primarily a new algorithm, the paper should make clear how to reproduce that algorithm.
(b) the contribution is primarily a new model architecture, the paper should describe the architccture clearly and fully.
(c) If the contribution is new model (e.g., a large language model), then there should either way to access this model for reproducing the results or way to reproduce the model (e.g., with an open-source dataset instructions for how to construct the dataset).
(d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reprodueibility. the case of closed-source models, may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers have some path to reproducing or verifying the results.
5. Open access to data and code
Question: Does the paper provide open access to the data and code, with sufficient instruc- tions to faithfully reproduce the main experimental results, as described in supplemental material?
14

---

Answer: [Yes]
Justification: Abstract.
Guidelines:
The answer NA means that paper does not include experiments requiring code.
Please see the NeurlPS code and data submission guidelines (https://nips.cr
for more details.
While we encourage the release of code and data, we understand that this might not be possible, so "No" an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for new open-source benchmark).
The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https
/ cpippi.ccppulli//uuuii wwwticccguie//eeieeeeeeii CoodeSubeiiie ssi wsionnolli onnolicy)))) for more details.
The authors should provide instructions on data access and preparation, including how access the raw data, preprocessed data, intermediate data, and generated data, etc.
The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only subset of experiments are reproducible, they should state which ones are omitted from the script and why.
At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).
Providing as much information possible in supplemental material (appended to the paper) recommended, but including URLs to data and code permitted.
6. Experimental setting/details
Question: Does the paper specify all the training and test details (e.g., data splits, hyper- parameters, how they were chosen, type of optimizer, etc.) necessary to understand the results?
Answer: [Yes]
Justification: Section
Guidelines:
The answer NA means that the paper does not include experiments.
The experimental setting should be presented in the core of the paper to level of detail that is necessary to appreciate the results and make sense of them.
The full details can be provided either with the code, in appendix, or as supplemental material.
7. Experiment statistical significance
Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?
Question:
Answer: [Yes]
Justification: Appendix D
Guidelines:
The answer NA means that the paper does not include experiments.
The authors should answer "Yes" if the results are accompanied by error bars, confi- dence intervals, statistical significance tests, at least for the experiments that support main claims of the paper.
The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, overall run with given experimental conditions).
The method for calculating the error bars should be explained (closed form formula, call a library function, bootstrap, etc.)
The assumptions made should be given (e.g.. Normally distributed errors).
should be clear whether the error bar is the standard deviation the standard error of the mean.
15

---

It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have 96% CI, if the hypothesis of Normality of enrors is not verified.
For asymmetric distributions, the authors should be careful to show in tables or figures symmetric error bars that would yield results that are out of range (e.g. negative eтror rates).
If error bars are reported in tables or plots, The authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.
8. Experiments compute resources
For each experiment, does the paper provide sufficient information on the com- puter resources (type of compute workers, memory, time of exccution) needed to reproduce the experiments?
Question:
Answer: [Yes]
Justification: Section
Guidelines:
The answer NA means that the paper does include experiments.
The paper should indicate the type of compute workers CPU or GPU, internal cluster, cloud provider, including relevant memory and storage.
The paper should provide the amount compute required for each of the individual experimental runs well estimate the total compute.
The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary failed experiments that didn't make into the paper).
9. Code of ethics
Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics
Answer: [Yes]
Justification: Ethics.
The research presented in our paper conforms with the NeurIPS COde of
Guidelines:
The answer NA means that the authors have not reviewed the NeurlPS Code of Ethics.
If the authors answer No, they should explain the special cireumstances that require deviation from the Code of Ethics.
The authors should make to preserve anonymity (e.g.. if there is special consid- cration due to laws or regulations their jurisdiction..
10. Broader impacts
Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?
Answer: [NA]
Justification:
Our research outcomes not have direct societal impact.
Guidelines:
The answer NA means that there is no societal impact of the work performed.
If the authors answer NA or No, they should explain why their work has no societal impact why the paper does not address societal impact.
Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.
16

---

The conference expects that many papers will be foundational research and not tied particular applications, let alone deployments. However, if there is direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.
The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology being used intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.
If there negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms monitor how system learns from feedback over time, improving the efficiency and accessibility MI..
11. Safeguards
Does the paper describe safeguards that have been put in place for responsible release of data models that have high risk for misuse (e.g., pretrained language models, image generators, or scraped datasets)?
Question:
Answer: [NA]
Justification: Our paper poses no such risks.
Guidelines:
The answer NA means that the paper poses such risks.
Released models that have high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere usage guidelines or restrictions to access the model or implementing safety filters.
Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.
We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make best faith effort.
12. Lieenses for existing assets
Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper. properly credited and are the license and terms of use explicitly mentioned and properly respected?
Answer: [Yes]
Justification: Section Appendix E
Guidelines:
The answer NA means that the paper does existing assets.
The authors should cite the original paper that produced the code package or dataset.
The authors should state which version of the asset is used and, if possible, include URL.
The name of the license (c.g., CC-BY 4.0) should be included for each asset.
For scraped data from a particular source (c.g., website), the copyright and terms of service of that source should be provided.
If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswi thcode. com com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of dataset.
For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.
17

---

If this information is not available online, the authors are encouraged to reach out to the asset's creators.
13. New assets
Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?
Answer: [Yes]
Justification: Appendix B
Guidelines:
The answer NA means that the paper does not release new assets.
Researchers should communicate the details of the dataset/code/mmoel as part of their submissions via structured templates. This includes details about training, license, limitations, etc.
The paper should discuss whether and how consent obtained from people whose asset is used.
At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.
14. Crowdsoureing and research with human subjects
Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well details about compensation (if any)?
Answer: [NA]
Justification:
No crowdsourcing nore research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsourcing nor research with human subjects.
Including this information in the supplemental material is fine, but if the main contribu- tion of the paper involves human subjects, then as much detail as possible should be included the main paper.
According the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.
15. Institutional review board (IRB) approvals or equivalent for research with human subjects
Question:
Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?
Answer: [NA]
Justification:
No crowdsourcing nore research with human subjects.
Guidelines:
The answer NA means that the paper does not involve crowdsoureing nor research with human subjects.
Depending the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtained IRB approval, you should clearly state this in the paper.
We recognize that the procedures for this may vary significantly between institutions and locations, and expect authors to adhere to the NeurlPS Code of Ethics and the guidelines for their institution.
For initial submissions, do not include any information that would break anonymity (if applicable), such the institution conducting the review.
16. Declaration of LLM usage
18

---

Question: Does the paper describe the usage of LLMs if it is important, original, or non-standard component of the core methods this research? Note that if the LLM used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigorousness, or originality of the research, declaration is not required.
Answer: [Yes]
Justification: Appendix A
Guidelines:
The answer NA means that the core method development in this research does not involve LLMs any important, original, non-standard components.
Please refer to our LLM policy (https: /ttpaarrpp..cc//ooofeeeeeee///// for what should or should not be described.
19

---

A AI Use Declaration
Code was developed with support from GitHub Copilot. ChatGPT was used for editing for grammar and clarity in some sections.
B SCATE Prompt
20

---

SCATE Time Normalization in Python
Introduction
Time normalization is the task of translating natural language expressions of time into standardized representation. The SCATE (Semantically Compositional Annotation of Time Expressions) framework represents different time expressions in compositional manner, formally defining the semantics of various time expressions and representing the normalized time expressions as mathematical operations intervals on timeline.
Key Time Concepts
Concept
Description
The infinite sequence of time points which time expressions should be anchored. Each point marks the start of second (e.g. 2015-08-03 09:35:47).
Timeline
An interval on the timeline, defined by starting point (inclusive) and ending point (exclusive). E.g., "1990" corresponds [1990-01-01, 1991-01-01).
Interval
Repeating interval
A sequence of intervals on the timeline. E.g., "Friday" refers to every Friday each week, sequence of intervals that repeats infinitely.
An amount of time, expressed as counts of standard time units. Periods are independent of the timeline. E.g., "10 weeks" doesn't have specific start/end points.
Period
Temporal
A function that takes periods, intervals, and/or repeating intervals as arguments and produces new periods, intervals, repeating intervals.
operator
Basic Usage
When using the SCATE library, the basic approach is to:
1. Identify time expressions in text
2. Generate the corresponding SCATE Python code for those expressions
API Reference
Interval Classes
class Interval/starrt:dateeinn end:ttttemme)
Interval
implements the SCATE interval definition. Defined by starting point (inclusive) and an ending point (exclusive).
Example:
21

---

Representing the year 1990
Interval
start-datetime datetime. fromisoformatt( (1190-01-01100000000)) end-datetime. ime fromisoformat ("1991-01-01100:000000))
Methods
iclassmethod
Interval Interval..froiisofonnn (aaaarae. Interval
Creates an Interval from two dates in ISO 8601 format.
Example:
Representing May 1362
Interval.tromisotormee (00.00omm00000012222000000000000 1382-06-01700:000000)
or more concisely Interval.fromisofoore "1362-05-01 1362-06-01")
Eclassmethod
Interval of (*args:int))
Interval
Creates an Interval that aligns to exactly one calendar unit.
Parameters:
*arge (int) A starting point specified by any prefix of the list: year, month, day, hour, minute,
second, microsecond.
Examples:
# Representing the year 1990 ofttervllof(1900)
# Representing April 1, 1918 (11118, 4,
Intervals Class
class Intervals ( Interval))))
A collection intervals on the timeline. This class implements the Python Iterable interface to allow iteration over set of Interval objects.
Usage:
This class is typically returned by operations that produce multiple intervals, such as LastN NextN, and These.
NthN
22

---

Unit Classes
class Unit (enum. Enum)
A named unit of time.
Available units:
MICROSECOND
MILLISECOND
SECOND
MINUTE
HOUR
DAY
WEEK
MONTH
QUARTER_YEAT
YEAR
DECADE
QUARTER CENTURY Y
CENTURY
Methods
Unit.
-> datetime datetime
Sets all units smaller than this the datetime
(nitt.rellt:iveeelta(()) dateutil. rrtzautil.rellatiiveeeee... relltvieeellaa...
Constructs a relativedelta object representing a number of repetitions of this unit.
Unit. Unit. (naiteeeppn((itteervalltttttte m:int-l)
Interval
Expands an interval to the width of a number of repetitions of this unit.
Shift Classes
class Shift
Base class for objects that be added subtracted from time point yielding Interval.
23

---

class Period P Uniit:
n:int] None)
Shift
Implements the SCATE Period definition. amount of time, expressed as counts of standard time units.
Example:
Representing "three
Period(KONTH,
class perfodddim/pprr.cdd.d.i//eeddl)) Shift
A period whose duration is the sum two or more periods.
Example:
# Representing "two years and a day" PeriodSum( [Period YEAR, 2), (DRY, 1)11
Repeating Interval Classes
class Repeating ( vange:Unit-None,
value:int-Kone, n_ unnits:int-1) Shift
Implements the SCATE repeating interval definition. Repeating identifies intervals are named by calendar system and repeat along the timeline.
Examples:
Representing all months of "February" Repeating YEAR, value-2)
# Representing all generic calendar "day" (DDesting((AAY)
Representing 'Thursday' (Monday-0, so Thursday-3) (epeating WEEK, value=3)
Predefined Repeating Intervals
24

---

Class
Description
Spring
Meteorological springs in Northern Hemisphere (March-May)
Summer
Meteorological summers Northern Hemisphere (June-August)
Fall
Meteorological falls in Northern Hemisphere (September-November)
Winter
Meteorological winters in Northern Hemisphere (December-February
Weekend
Weekends (Saturdays and Sundays)
Morning
Meteorological mornings, 06:00 until 12:00
Noons, 12:00 until 12:01
Afternoon
Meteorological afternoons, 12:00 until 18:00
Day
Meteorological daytime, 06:00 until 06:00
Evening
Meteorological evenings, 18:00 until 00:00
Night
Meteorological nights, 00:00 until 06:00
Midnight
Midnights, 00:00 until 00:01
Composite Interval Classes
EveryNth Class
class Everytthh@hifft:shifft, m:int)
Shift
Creates a repeating interval that selects only every nth occurrence of another shift pattern.
Parameters:
The base shift pattern
How many occurrences to skip between each selected occurrence
Example:
# Representing "every other Friday" ( WEEK, value=4), n=2)
ShiftUnion Class
Shiftunion titt
Creates a union of two or more shift patterns, including all occurrences from each pattern.
Parameters:
25

---

shifts collection of shift patterns combine
Example:
Representing "Mondays and Fridays"
ShiftUnion(
Repeating WEEK, value-0), Monday
Repeating WEEK, value-4) Friday
1)
Repeatinglnterssctioon Class
class hepprttiingneerrrrrrrtooootitttt R
-> Shift
Creates an intersection of two more repeating intervals, including only times that satisfy all patterns.
Parameters:
shifts
A collection of repeating intervals to intersect
Example:
# Representing "Saturdays in March"
Repaatingtntersectoon))
Repeating WEEK, value=5), Repeating (MONTH, value=3) March
Saturday
Year-specific Classes
class (daiiiistss _niisssing_dggitssiin--0)
Interval
The interval from the first second of year to the first second of the next year. With missing digits parameter, can also represent longer intervals such decades, centuries, millennia.
Parameters:
digits
The significant digits of the year or time period
missing digits
The number of trailing digits omitted, determining the granularity:
O: represents single year (e.g., 2014), from the first second of the year to the first second of the year
1: represents decade (e.g., 201X or the 201 spanning 10 years
2: represents century (e.g., 20XX the 2000s), spanning 100 years
3: represents millennium (e.g., 2XXX or the 2000s millennium), spanning 1000 years
Examples:
26

---

kepresenting the year 2014 (201() [2014-01-01100:000000 2015-00--01100:000000
Representing the decade of the 1980s Year [eiissing_dggis=i]) [1980-01-01100::0:000, 000000000000000000000000:0000011
Representing the 20th century Year (19, n missing digits=2)
[1900-01-01000::::000 2000-01--01000:00000000
Representing the 2nd millennium [1000-01--11000000:0000,, 2000-01--1100:00:000 Year (1, missing digits=3)
class rearsuffixcittervalllmeeee digits:int, m_miisingg_diiitsiinnte Interval
A year-long interval (or longer mimsing ) created created from the year of another interval and suffix of digits to replace that year. Like Year class, with n m_mmssinnggdie digits can represent decades, centuries, etc.
Parameters:
interval
The reference interval containing the base year
digits
The digits to use as the suffix of the year
n beasiing_iiiite The number of trailing digits omitted, determining the granularity:
O: represents single year
represents decade
2: represents century
etc.
Examples:
Representing the year "96" in the context of 1993 (becomes 1996)
YearSuffiix digits=96) # [1996-01-01100:00:
0007000000000000000000
Representing the decade "20s" in the context of 1993 (becomes 1920s) (earSufflx(Year(11 (1993), digits-2, missing digits-l) 01:00:00:00)
[1920-01-01100:00::: 1930-01-
Ordinal Centuries Anniversaries
Text
SCATE
Nth ithhinterval-Noee, shifftreepeetingiliittcnowa range-CBNTURY) index-20)
20th century
100th
Nth ithhinterval=None, shift:sprrioduuntt-aaaa n=None), index=100 100)
anniversary
27

---

Nth for ordinal references to long-span intervals. If no explicit anchor interval is present, set Lnterval-None and resolve contextually in post-processing step.
Temporal Operators
Last Operators
class Last (nnttinntelll:ntereea shift:8hift, interval included: bool-Faasee -> Interval
The closest preceding interval matching the specified Shift.
Example with Period:
Representing "aver the four days" (in the context Nov 2024) Last Last( oI 11, 1), Period(DAY, 4))
Example with Repeating:
Representing "Tuesday" (in the context of Tue Nov 2016)
The speaker references the current day
Last(
interval.of(2n) Repesting (DAY, WEEK, value-1), Interval included-True
Lasti shift:shift, niint, interval include::bool-Falee) Intervals
Repeats the Last operation n times.
Example:
Representing "the previous two summers" (in the context of 29 May 1264) of 29,, Summer(), n=2)
Next Operators
class (nnt(iiitralll::terree shift:Shift, interval thocluudddbbolFFallle -> Interval
The closest following interval matching the specified Shift.
Example with Period:
Representing "the
hours" (in the context 2024)
Next (22044, 11, 1), Period(HOUR, 3))
Example with Repeating:
28

---

kepresenting "the coming week" (in the context of 14 Feb 1912) Next (Interval. 2, 14), Repeat.igg (WBEK) )
class (eettl(iantervall:nteeeaa shift:shift, n:int, interval tholludd:bbol-Faalee >> Intervals
Repeats the Next operation n times.
Example:
Repzesenting "the next six Fridays" (in the context of Sat 22 Dec 1714) Mexth((nnterva.oo((1114 12, 22), (epeating(DAY, WEEK, value-4), n-6)
After Operators
class atterrinttervallitttevvl,l shift:shift, n:int=1, interval incluleed:bool=FPalee Interval
Moves the input Interval later by the specified Shift the specified number of times.
Example with Period:
Representing "a month later" (in context of Sep 1595)
After After Ifteerell.ff 13), Period(MNNTH
Example with Repeating:
Representing "three Aprils after" (in After(
1993)
of 1, 23), Repeating (MONTH, YEAR, value=4), n=3
Important Differences Between Next and After
There are important behavioral differences between the Next and After operators:
With Periods:
They behave very differently: After moves the reference interval by the specified amount, while Next takes the period following the interval:
>>> ifteer 4, 12), (WEEK, 3) iisoformat( '2024-05-03700=000:00 2024-05-04700:00.00
>>> (1tteteaavval,, 4, 12), PerLod 3)) iisoformat(
"2024-04-13700:00:00 2024-05-0440::00000
29

---

With Repeating Intervals and n-1 (default):
They produce identical results:
>>> (f
Repeatiing(EEx) isoformatt
'2024-04-16100:000:00 202-004-23T0-- 00:00
>>> (extt 4, 12), Repeating (WEEK) isoformst()
"2024-04-16700:000000 202-000--20002222200:00000000000
With Repeating Intervals and n>1:
They diverge significantly: After returns single interval (the nth one), while NextN returns intervals:
>>> (204 4, 12), Repeating ar3).isoformat:
'2024-01-30700:000::0 2024-05-07700:00::0
>>> Nex:3((aaterval.oo 12), repeating(KEEK) n-3) isoformats()
["2022-01-110700:00::::0::: 200.::::0000000000000000000000:0 '2024-04-33T00000000 2024-00-30700:00:00"" "2024-004-20000:::000000000000 0000::00000000000000000000000000
Note: In the pyscate/normit..ime inplenetatiio,,,,,,,,,,,,,,,,,,, you need to use NextN instead of Next: to access the
argument functionality.
Before Operators
class Before Before (iteerval: shift:Shift, nsint=1, interval included: bool-aaaee) Interval
Moves the input Interval earlier by the specified Shift the specified number of times.
Example with Period:
Representing "a year ago" the context of 13 Sep 1595) Befoore 9, 13), PeriR 1))
Example with Repeating:
Representing "two Tuesdays before" the context of Sat: 23 Jan 1993) Before(
Interval.of 1, 23),
Repeating(DAY, value=1), n=2
Nth Operators
Wth(intteval::nterva.l shiftishift,
index: int,
Selects the nth repetition of a Shift starting from one end of the Interval.
Examples:
30

---

Representing "fiftieth day of 2016" (cheer (epeatinggDDV)) index=50)
Representing "Thirdtto-astt Sunday of 2024" Nch(Year(2024), Repeating(DAY, WEEK, value=6), index=3, from_endd end=True)
class (taM(Inntrralllntteeeell shift:Shift, Intervals
index: int, n:int, from sron_end:bool-Falae >>
Selects specified number of nth repetitions of Shift starting from one end of the Interval.
Example:
# Representing "the second six Mondays of 1997*
NthN Year (1997), (epeating(DAY, WEEX, value=0), index=2, n=6)
This Operators
(hirellateralll:tteerraall shift:Shift)
Interval
Finds the interval containing the given interval based on the specified Shift. Example with Period:
# Representing "these six days" (in the context of 29 Apr 1176)
This [I 4, 29), Peri 6))
Example with Repeating:
# Repzesenting "this January" (in the context of 10 Nov 1037) This of 11, 10), Repeating YEAR, value=1))
These Operator
class These (heer shift:Shift)
Intervals
Finds all instances of the specified shift pattern within the given interval. This operator first identifies the containing range of the specified shift type, then finds all individual shift units within that range.
Parameters:
interval
The containing interval to search within
shift
The shift pattern to find instances of
Example:
31

---

Representing "Tuesdays and Thursdays in January 2025" These(
(f 1),
ShiftUnion([
Repeating(DAA,, WEEK, value=1), Tuesday Repesting(DAY, WEEK, value=3) Thursday
Between Operator
class between(stary (ttrteteettatt_tteeallllaaa interrallIItervaa end interval :nteerval, start_ haa____hcciddee:oooo--aeee.e end
Interval
Selects the interval between a start and an end interval. This creates a new interval that spans from the start Interval to the end interval.
Parameters:
interval
The beginning interval
end interval
The ending interval
start included
Whether to include start interval in the result
end included Whether to include the end interval in the result
Example:
Representing "since 1994" the context of 09 Jan 2007) Between ( Year (1994), (200,,, 1, 9))
Quick Templates
Pattern
SCATE Template
since X
Between(stard interval=t,, end interval=0CT)
weeks before
Last iinttereavv, shift=PPerioddmiittwaeee n=None))
Use these templates for constructions such as since 1985, since March, or weeks before the attack.
Intersection Operator
class
Interval
Selects the interval which all given intervals overlap. This creates new interval that represents the common timespan where all input intervals coincide.
Parameters:
intervals A collection of intervals to find the intersection of
32

---

Example:
Representing "earlier that day"
# (in the context of "We met at 6:00 on 24 Jan 1979")
Intersection(1
(fntervalvalof (19799, 1, 24, 6), None), tfterval.of 1, 24)
1)
Time Expression Annotation Examples
Once you understand the SCATE framework, you can start annotating time expressions in text. annotation process involves:
1. Receiving the document creation time (DCT) and text as input
Identifying time expressions the text
3. Writing the corresponding SCATE code for each expression
Financial and Reporting Period Time Expressions
Financial reports, earnings statements, and business often contain specialized time expressions related to fiscal periods:
Quarter references in financial contexts:
Expression
Context
Correct Representation
Incorrect Representation
Eocil Liteevvl-Bthhc Lattevvaaavl (digtttee
This Lnterval- digg shi Et-llspeat tun t-QUARVER YEAR, Vang, value=31)
"third- quarter"
Past
wh if Ett.ttttettttee ing iit-QUAATEER, YEAR, range=QUAReER, YEAR),
index=31, sbife-PPrriodruatt-eea
articne))
"Q2
This -Year (YAg
Current
results*
whifttrlepwating iniiAUUART YEAR, range-YEAR, value=2))
'next
Future
quarter"
range-QUARTER YBAR)
2. 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")
Year-ago comparisons:
Expressions like "year-ago quarter" or "same quarter last year" should use Before with period of year
Example: Before wnt.erval-hisinteeeeveeeee
shitt-Repetting(ultt-UURRE YEAR, range=QUARTER YEAR) shift==eriiodunitt-rae n=1))
Key principles financial time expressions:
Financial quarters have specific calendar alignments (Q1:Jan-Mar, Q2: Apr-Jun, etc.)
33

---

The fiscal year may differ from the calendar year depending on the company
Always consider whether the reference is to the current reporting period or comparison to previous period
Use the appropriate operator (This, Before, statement
Next
based on the temporal context of the
Temporal Adverbs and Their Appropriate Operators
When annotating temporal adverbs, it's crucial to select the correct operator to accurately represent the time relation:
Temporal Expression Category
Appropriate Operator
Examples
Example Code
previously, formerly, earlier, before, the past, ago
Last Lnnterval-DCT
References
Laat
shi
This (iii(iieleval-DC
Present References
now, currently, presently, at present
This
shi Et-None))
Future References
soon, later, in the future
Next
sbiff=Hoone)
Examples of correct annotation for temporal adverbs:
# For "previously" in text with DCT of 2021-05-15 (ate: 5, 15), shift=None)
For "currently" in a text with DCT of 2021-05-15 (hiss 5, 15), shift-Wone)
For "later" in text with DCT of 2021-05-15
Next iattt 5, 15), shift=None)
Comparative Adverb + Named Day
Text
Correct SCATE
Span
earlier
Intersection [ieesaetttot((fffooeeeeeeeerlloo shift=None), This(interval=Der, Lut range-WEK,, value-6))1)
Sunday
later
Intrracctooo(/ttee(((leerraaaoon shift-None), [hie(Lnterval-DeT,
Monday
shittt-Repettingg((tttDDAyy range=NEEK, value=0))])
prior
befoze(Lnterval-pp) shift--Rppatinnguul---aaa range-YEAR))
year
34

---

When a comparative adverb (earlier, later, prior, following, etc.) immediately followed by a named calendar unit (day, month, year), treat the whole phrase as one time expression and combine the semantics with Intersection (or Before separately.
After
Never annotate the adverb and the named unit
Contextual Time Reasoning and Future Date Inference
When annotating time expressions, particularly in business, financial, and legal contexts, it's crucial to correctly infer whether a date refers to the current year or a future year:
1. 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"
2. Date logic with Document Creation Time (DCT):
Correct
Expression
Context
DCT
Correct Representation
Interpretation
Next (iaterval-BCI,
"peyable Jan. 2"
November 1989
2
January
Fe=Regeat ing (Regeat ing (nn inguunit=M0077, range=VIaAR, RepatingtunittDD
Next (1aterval--CI,
"record Dec. 15'
November 1989
December 15, 1989
'De. 15"
Ft=Regeat ing
[Regeat i ing( range=YEARR
valse-12), IngestrnggunittDAA,, range-M0677, value-13]]))
"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, reference is to that month the next year; otherwise is the upcoming occurrence within the current year.
Example (DCT 1998-03-01): "last February" 1997-02 (previous year), "next February" 1999-02 (next year)
3. Month sequence reasoning:
month mentioned earlier in the calendar than the DCT month, and context suggests future event, it typically refers to that month in the following year
Example: DCT is November 1989, then "Jan. 2" likely refers to January 2, 1990, not January 1989
4. Common patterns in financial announcements:
Dividend/ppyment announcements typically include:
declaration date (usually the DCT before)
record date (usually in the near future)
payment date (usually after the record date)
Example: "The dividend is payable [payment date] to shareholders of record on [record date]"
Incorrect annotation patterns avoid:
Never default This (iittervvvvleee (digitt-ARR))) ...) for dates without explicitly considering whether they refer to the current or future year
35

---

Don't assume months mentioned in always refer the current year
Pay attention to the logical sequence of events implied by the text
Handling Prepositions in Time Expressions
When annotating time expressions, pay careful attention to whether prepositions (like "over", "during", "within", etc.) should be included as part of the time expression treated separately:
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
2. Examples of proper boundary detection with prepositions:
Text
Correct Expression
Incorrect Expression
"over the weekend"
"weekend"
"over the weekend"
"during the summer"
"summer"
"during the summer"
"on Tuesday"
"Tuesday"
"on Tuesday"
Note: The preposition may affect the interpretation (e.g., "over the weekend" implies the entire weekend), but the expression itself typically just the temporal noun phrase.
Handling Vague Duration Expressions
For vague expressions of duration or relative time, use the appropriate operators:
1. For expressions implying a non-specific duration:
Expression
Correct Representation
Incorrect Representation
'within few
(interval-t) Pbiif
Next
days'
[=None) }
1), n=3)
"in several weeks"
Sexth (interval-Doe ICDCY, whi FtePer inn. D=Foge)
Nexthi interval wh Ft-Period MEEK,
1), n*X)
"for some months'
Next Next (interval-DCC Piiitt-Prrodd(unit--o0rrr
Specific number months
(=Nonne)
2. Key points about vague durations:
Use n=None to indicate an unspecified quantity
Prefer Next with vague period over NextN with a specific count for naturally vague expressions
Don't try to quantify inherently vague expressions with specific numbers
3. Common vague time patterns:
"a few X" Period(unit=x, n=None)
"several X" - Period(unit=X n=None)
36

---

"some Period(unit=XX 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 identify the level of specificity intended in the expression:
format dates (WWY-MM-DD):
Full date formats like "1998-08-07" should be annotated with day-level specificity, not entire year
Incorrect Representation
Expression
Representation
This interval (Verrr chit=-mepecinnggnterrrrrroooooee [Repeat: Lng unnie=oout,, ranga=YEAl, value-B), Lagpattig cange-MONts, value=?:]] })11)
"1998-09.
Year (digitsi (aagggtta9198))
07
This Linterval digite- hal.eeooossiiiittreesiinnee. (eepestiigguunnn-eeeen range-YEAR, value-12), tepestinggunitt-DAy, rangerHORTE, value=31)111)
'2020-12-
Year 2it22002)
2. Common date format variants:
American format (MM/DD/WYY) "0800/9998
European format (DD/MM/YYY): "07/08/199
All should be normalized to the same SCATE representttion when they refer to the same date
Metadata dates:
Dates appearing in document headers, bylines, or metadata sections should be treated with the same precision they express
standalone date like "1998-08007" a document header still refers to that specific day
4. Key principle: Always preserve the temporal granularity expressed in the original time expression. Never default to a broader time range (like a year) when more specific one (like a day) explicitly stated.
Precise Annotation of Common Deictic Time Expressions
Common deictic time words require special attention to preserve their precise temporal meaning:
1. Day-specific expressions:
Expression
Correct Representation
Incorrect Representation
"today"
This (h:teenntevvl-DCC =bift= www.::ppppetiiiouutootaaaaa (Dni range-DAX)
mhis(intervai-Der shife=None)
"yesterday"
Last (ineevval-Dee, whi thif:==nippeeeinnngnnitaaaaa range-BAY))
fast: (interval-DCT, wh Xon
"tomorrow"
Bext (intevvvvvo,,, ehift=-epeeriing(uiitooay range-DAY)
(ittevvvaa,,
2. The importance the shift parameter:
Using shift-Mone loses the specific temporal granularity of the expression
37

---

words like "today", the ahifft-Beepattinn((nnt-DDD; range-DAY) indicates refers specifically to a day-long period
This preserves the precise 24-hour meaning rather than treating it generic "current time"
reference
3. Other common deictic expressions and their correct representations:
Expression
Correct Representation
"this month"
ihis
shift-Rkgeetiing(uutt----o range-KONтH)
"this year"
(his @hifttRRgeeatingguuttt--aaa. range-YEAR))
"next week"
(inteeralvll-
shiff=RRpeetinnguuii-t-Bann range-WEBX))
"last night"
iinteevvcvl, shift=wight())
4. Calendar-Aligned "last past N" Expressions:
Whenever the intent include complete calendar units (year, quarter, month, week, night,
weekend ...), choose Repesting) not Period.
Period is limited to rolling or vague durations that do not align exactly to named calendar units.
Expression
Correct Representation
Why
Use Repeating that the interval aligns Jan of
year"
Sepet-Sepeating VEn,: range-YZhR()
the previous calendar year, rolling 365-day window
Laath interval-DCr shift=Repeutinn (un range=YSAR), n=3)
"past three years*
alignment logic above
LaaeN] interva interval-Dcyy loCC,
"last five quarters'
abifttBepeation (UNAE-QUARTER, YEAR,
Quarter-level repeat
range=QuARTen, YEAR), n=5)
5. 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 time expressions, it's crucial separate core temporal references from their modifiers determiners:
1. Core time expressions vs. extended phrases:
38

---

Full Phrase
Core Time Expression
Modifiers (Not Part of Expression)
"at the end of November"
"November"
"at the end of
"today's editions"
"today"
editions"
"by early December"
"December"
"by early" "throughout"
"throughout next week"
"next week"
"in the past"
"past"
"in the"
Principles for identifying core time expressions:
The expression contains the essential temporal reference (day, month, year, etc.)
Adjectival markers like "'s" (possessive) usually indicate the end of the care expression
Prepositions ("at", "on", "by", "during") typically precede but aren't part of the core expression
Modifiers like "beginning of", "middle of", "end of" should be excluded from the core expression
3. 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's" vs. "yesterday"
Comparative-adverb named-day phrases (e.g.. "earlier Sunday", "later Monday") must not be split;
4. Correct annotation examples:
Correct
Text
Incorrect Annotation
Annotation
"The meeting November"
of
time_text:
time_texe text: "at end of November"
"November"
was reported in today's newspaper"
time_text: "today"
time_textt "today's newspaper"
iemettext: "next week"
"They'll arrive by early next week"
time_text: "by early next week"
Common patterns 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")
Articles and Quantifiers in Time Expressions
39

---

When annotating time expressions, important understand how articles (a, an, the) and quantifiers interact with the core temporal expression:
1. Articles time expressions:
Correct Time Expression
Full Text
Notes
The indefinite article "a" not part of the time expression
year earlier"
"year earlier"
week ago"
"week ago"
The indefinite article excluded
"the previous
"previous month"
The definite article is excluded
month"
2. 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")
Relative time expressions with articles:
Expression
Correct Representation
Notes
"a year earlier"
Before((nterval-DCC)
Use n-None for unspecified duration
mhiff==Pariioduniitttt// n=None))
"a year ago"
(iseervaravll
Use specific n=1 because "a year" specifies exactly one year
thiffttPeriodduiittr//ee n=1))
few
Lintttinterval=000,
Use n=None for vague durations like few"
weeks ago"
shifft=Perriodduii--WWE.., n-None)
4. Comparative time expressions:
"earlier", "before", "prior", "previous" - Use Before operator
"later", "after", "following": "subsequent" Use After operator
"ago" Use Last operator
Key points remember:
Focus on annotating just the minimum temporal expression needed to convey the complete meaning
Be consistent in excluding articles across all annotations
Pay attention to whether the time reference specific (e.g., "a year" exactly year) or vague (e.g.. "some years" unspecified number of years)
Example Annotations
40

---

When annotating time expressions, we need output the time text and its corresponding SCATE representation. output should in JSON format with list objects, each containing:
t Lime text: : The text span containing the temporal expression
scate:
The SCATE code that represents this expression
Here's an example of the annotation process:
Input:
DCT: 1998-05-01
Text: The Internet, the global network of computers, is now far reaching into the country include every and cranny nation opening only diverse range information sources
exxending
exhaustive 1ist
possibilities to create new applications which to people' lives.
Output:
"time_tex"" "now", "scate": "iii 1), shift-None)"
Here examples:
Input:
DCT: 1998-05-01
Text: AP019980501 01w.:/00.....0011110000000/99990 0413:000hhh1///49999550000000 NEWS STORY 05/01/1998
09: 09:13:00\mw2844 cxlf watmr w Cx13 Cx11 SETTING-THE-STAGEBSEE 05-01 0665 INGETII
STAGE AMALYYAA Setting the stage for Net convergence, NEW STRAITS PIMES-MANAGEMENT
TIMES xfdws SETTING-THE-STANE sked Emerging Markets Datafile April 30, 1998 NEW
STRAITS TIMES MANAGEENN TIMES ENGLISH COPYRIGHT 1998 BY WORLDSOURCES, INC., JOINT
VENTURE FDCH, INC. AMAND WORLD TIMES, INC. \nNO PORTION OF THE MATERIALS CONTAINED
INC. \mNAAAYYMMALAYSA aggressive APTRIDUTION WORLDSOURCES,
HEREIN
information age could come
opportune time.
Output:
"rimm_texx":: "05/01/1998 09:13:00",
"scate": "Miissiineeevaaaerrrdggssssss99 shittessppeccagggtteeeeetttotoee
(Repestinggunit--OONT,, range-YRAR, value-5), (unit-DDA, range-XONTH, value-1),
Repest.ing(untt-HOOB,, range-DAY, value-9), (tnbtttinn(unltMMNNUP,, range-HOUR, value-13),
range-MINUTE, value-0)])))
41

---

"time_text"" ; "1998", "scate": "dgit_99g },
"time_text": text": "April 30, 1998",
"scate": "hissaatteva--rrrriiissssss- aiittrieppaiiigggtttreeteooooioo
(nnp range=YEAR, value=4), (epeating(unittDAAY, range=NONTH, value=30)1))
},
"time_text"; "time",
"scate": "hirsiiieeeaa.mmea..oo....... 1), shift=None)"
},
More Important Notes for Annotation
The document creation time (DCT) provided input along with text
2. Focus identifying all time expressions the text and writing the correct SCATE code for each
3. Always output in JSON format with a list of objects containing time text and scate fields
Use the appropriate SCATE operators and classes based on the time expression semantics
5. For deictic expressions (like "now", "today", "yesterday"), use the DCT as the reference point
For relative expressions (like "next Friday", "last month"), anchor them to DCT collection of intervals on the timeline. This class implements the Python Iterable interface to allow iteration over set of Interval objects.
Time expressions in the output JSON must be ordered according their appearance the original text
8. Always consider the hierarchical nature of time expressions and their composition
9. Pay special attention to temporal adverbs and prepositions:
Words indicating past time (previously, , before, earlier, formerly.
past, etc.)
should typically use the Last operator, not This
Words indicating future time (soon, later, in the future, etc.) should typically use the Next operator, not This
Words indicating present time (currently, presently, at the moment, etc.) should use the This operator
Common Annotation Pitfalls
1. Misinterpreting vague temporal adverbs: Words like "previously" or "formerly" indicate time before the reference time, they should be annotated with (attreeteral- shift-None) rather than This (Itervvanrl,, shift-None)
2. Confusing This vs. Last: The This operator refers to the current time interval, while Last refers to previous time interval. For example:
42

---

# Incorrect (for "previously")
This (nterreallnnttevellll 11, 2), shift-None)
# Correct (for 'previously")
hatt:.iinarrolsmtttavaa.../1111 11, 2), shift=None)
3. lgnoring contextual cues: Sometimes temporal expressions must be interpreted based surrounding context the text, not just the DCT.
4. Incorrect time expression boundary detection: Be careful when identifying the boundaries of time expressions. Pay attention
Time expressions that span multiple tokens (e.g., 08-07-98 0618 should be treated as single
expression)
Time zone indicators that are not part of the expression (e.g. EDT, GMT, UTC)
Whitespace that may separate parts of a single time expression
Fragmentation combined date-time expressions: Date and time components that appear together (e.g., "08-07-98 0618") should be treated as single time expression, not split into separate expressions.
Missing implicit time references: Some texts imply a reference without explicitly stating (e.g.. "previously" without stating when).
43

---

C Interval Few-shot Prompt
44

---

Input:
DCT: 1998-05-01
Text: The Internet, the global network of computers, is now far reaching into the country extending its embrace to include every nook and cranny of the nation opening doors to not only diverse range of information sources but also an exhaustive list of possibilities create new applications which add value people's lives.
Output:
"now", "normalized"; "... ..."
Input:
DCT: 1998-05-01
Text: APW19980501
Aww.1990000000000000///00//////1 0ww.0004000000/1999999909 09113000M/iinAP119999005 .0480 NEWS STORY 05/01/1998
09:13:00\mw2244 Cx1f wstmr Cx13 Cx11 SETTING-THE-STAGESked 05-01 0665VNSETTING-THESTIII
skedYnMALAYSIA Setting the stage for Net convergence, NEW STRAITS TIMES-MANAGEMENT TIMES QL xfdws SETTING-THE-STAN sked Emerging Markets Datafile April 30, 1998 NEW STRAITS TIMES- MANAGEMENT TIMES ENGLISH COPYRIGHT 1998 BY WORLDSOURCES, INC., AJOINT VENTURE OF FDCH, INCANAND WORLD TIMES, INCAnNO PORTION OF THE MATERIALS CONTAINED HEREIN MAY BE USED IN ANY MEDIA WITHOUT ATTRIBUTION TO WORLDSOURCES, INC.I\nninnMALAVSIAA aggressive move into the information age could not come a more opportune time.
Output:
"time text": "05/01/1998 09:13:00",
"scate": "1998-05-01109:13::0 1998-05-01T09:13:00
"time text": "1998",
"scate": "1998-01-01700:00:00 1999-01-01100:000000
},
"April 30, 1998",
"scate": (aaiiinntttalteerrrriggeeeee ailtt-Reppetinggtteeestttooooo (shifts-
(eepeatinguunit-MOrs rEARe-YEAR, value-4), Repeatiing(untt-DAY, range-MOWTH, value=30) J))" },
'time_text's text"; "time",
"scate": "1998-04-30700:00:0 1998-05-01700:000000
45

---

b,
Input:
DCT: 1989-11-02
Text: Integra-A Rights Offering 11/02/89 WALL STREET JOURNAL ()) ITGR HWG IRVING, Texasinlnnnhnninteraa-4 Hotel amp Restaurant Co. said its planned rights offering to raise about $9 million was declared effective and the company will begin mailing materials to shareholders at the end of this week.
Output:
"time_text"s text": "this week", "normalized'; "1989-10-30700:00:00 1989-11-06700:0:0000
},
"timeteet': "11/02/89",
"normalized"; "1989-11-0200::0:00 1989-11-07700:0:000
Input:
DCT: 1989-11-02
Text: Stephen Akerfeldt, currently vice president finance, will succeed Mr. McAlpine.
Output:
"time text":
"currently",
"normalized"; "...
46

---

D Additional Comparisons and Statistical Significance
D.1 Comparison with Existing Systems
We compare our method against both SCATE-based and ISO-TimeMIL-based time normalization
systems.
SCATE-based baseline We compare against the Neural Parser by Xu et al. [019]]. which represents the only publicly available SCATE-based implementation and the previous state-of-the-ard On the test set, the Neural Parser achieves an Fl score of 0.43 (Precision: 0.57, Recall: 0.35). Our method improves upon this by 37% in F1 score (from 0.43 0.59), demonstrating the effectiveness of our code generation approach over the previous sulti-stage LSTM pipeline.
ISO-TimeML baseline We also compare against SUTime [Chang and Manning 2012). widely- used rule-based time normalization system. SUTime achieves an Fl score of 0.45 (Precision: 0.58, Recall: 0.37) on our test set, while our method achieves 0.59, demonstrating the advantages of the more expressive SCATE framework.
Runtime comparison We conduct runtime measurements on the test set using an NVIDIA RTX 3090 GPU with vLLM [Kwon et al. 2023) for efficient inference. Our Qwen2.5-00 1wen2.5-0.5B model processes the entire test set in 6 seconds, compared 190 seconds for the Neural Parser's LLTM-basee pipeline, achieving a 31.7x speedup. This significant improvement stems from: (1) end-to-end generation eliminating multi-stage pipeline overhead, (2) efficient transformer-basee inference, and (3) smaller model size (0.5B parameters) enabling faster forward passes.
D.2 Confidence Intervals
We calculate 95% confidence intervals using bootstrap sampling, where randomly resample 80% of the evaluation data 100 times and compute evaluation metrics on each sample to estimate the statistical uncertainty of our model's performance. We present the results in Table ST and Table S2
Table S1: Performance of LLMs on Temporal Expression Recognition and SCATE Code Generation on Training Set with 95% confidence intervals. Values shown as mean + std, confidence intervals (CI): (lower, upper).
Model
Accuracy
Precision
Recall
F1
Claude 3.5
0.62 + 0.02 Cl: (0.62, 0.63)
0.64 + 0.02
0.62 + 0.02
0.63 + 0.02 Cl: (0.63, 0.64)
Cl: (0.64, 0.65)
C1: (0.62, 0.63)
Claude 3.7
0.69 + 0.02 Cl: (0.69, 0.70)
0.63 + 0.02
0.69 # 0.02 Cl: (0.69, 0.70)
0.66 # 0.02 Cl: (0.66, 0.67)
CI: (0.63, 0.64)
Gemini 2.0 Flash
0.65 + 0.03 Cl: (0.64, 0.65)
0.64 + 0.02
0.65 + 0.03 Cl: (0.64, 0.65)
0.64 + 0.03 Cl: (0.64, 0.65)
Cl: (0.63, 0.64)
Gemini 2.5 Flash
0.61 + 0.02 Cl: (0.61, 0.62)
0.63 + 0.02
0.61 = 0.02 Cl: (0.61, 0.62)
0.62 + 0.02 Cl: (0.62, 0.63)
CI: (0.63, 0.64)
Gemini 2.5 Pro
0.50 + 0.02 Cl: (0.50, 0.51)
0.65 + 0.02
0.50 # 0.02
0.56 = 0.02 Cl: (0.56, 0.57)
Cl: (0.64, 0.65)
Cl: (0.50, 0.51)
GPT-4.1
0.66 + 0.02 Cl: (0.66, 0.67)
0.60 + 0.02
0.66 # 0.02
0.63 + 0.02 Cl: (0.63, 0.63)
Cl: (0.60, 0.60)
Cl: (0.66, 0.67)
E
License information
We respect the license and intended use of models and datasets employed in this study. Detailed license information is provided below.
47

---

Table S2: Performance comparison of different methods on the test set with 95% confidence intervals. Values shown as mean + std, confidence intervals (CI): (lower, upper).
Methods
Accuracy
Precision
Recall
Fl
Qwen2.5-0.58 + Training Set
0.01 0.01
0.49 0.50
0.01 0.01
0.01 0.01 CI: (0.01, 0.01)
Cl: (0.00, 0.01)
Cl: (0.39, 0.59)
Cl: (0.00, 0.01)
Qwen2.5-0.5B CC-News
0.37 0.03
0,46 0.04
0.37 0.03
0.41 0.03
CI: (0.36, 0.37)
Cl: (0.45, 0.46)
Cl: (0.36, 0.37)
Cl: (0.40, 0.41)
Qwen2.5-0.5B + CC-News Training Set
0.04
0.04
0.04
0.04 CI: (0.58, 0.60)
CT: (0.58, 0.60)
CI: (0.59, 0.60)
CI: (0.58, 0.60)
Claude 3,7 + SCATE Prompt
0.49 = 0.03 CI: (0.49, 0.50)
0.56 # 0.04 CI: (0.55, 0.57)
0.49 # 0.03
0.52 & 0.03 CI: (0.52, 0.53)
CI: (0.49, 0.50)
Claude 3.7 + Interval Few-shot Prompt
0.38 # 0.03 Cl: (0.38, 0.39)
0.39 * 0.03 Cl: (0.38, 0.39)
0.38 0.03
0.38 0.03 Cl: (0.38, 0,39)
Cl: (0,38, 0.39)
GPT 4.1 SCATE Prompt
0.51 = 0.03 CI: (0.51, 0.52)
0.51 # 0.03
0.51 0.03
0.51 0.03 CI: (0.50, 0.52)
CI: (0.50, 0.52)
CI: (0.51, 0.52)
Models. The Claude family models utilized in our study are licensed under the Commercial Terms of Service, The Gemini family models are licensed under the Google APIs Terms Service The GPT-4.1 model is licensed under the Business terms The Qwen 2.5 models are licensed under the
Apache License 2.0.
Datasets. Use
The CC-News dataset used in our study is available under the Common Crawl Terms of
F
Detailed Error Analysis
To better understand the limitations of our best-performing model (Qwen2.5-0.5B + CC-News + Training Set), we conduct detailed error analysis on the test set predictions. We categorize incorrect predictions into five main types based on their root causes and provide representative examples for each category.
F.1 Error Distribution
We identify the following error distribution:
Missed expressions (70%): The model fails to identify temporal expressions that are annotated in the gold standard.
Boundary errors (10%): The model identifies temporal expression but with incorrect span boundaries.
Structural errors (10%): The model fails capture the correct compositional structure of complex temporal expressions.
Operator confusion (5%): The model selects an inappropriate SCATE operator despite correct span identification.
Granularity errors (5%): The model represents temporal expressions at incorrect levels of granularity.
F.2 Missed Expressions
The most critical failure mode occurs when the model completely fails to identify annotated temporal expressions. These account for 70% of all errors.
Example
Context:
"We estimated could do it in 100 days, and got across the 99th day."
Gold expression: "99th day"
48

---

Gold SCATE:
Nth
index=99)
Predicted: Missing
Analysis: The model struggles with ordinal expressions embedded in narrative contexts, possibly because they are less explicit than standard date formats.
F.3 Boundary Errors
Boundary errors occur when the model identifies the general location of temporal expression but fails to capture the exact span. These represent 10% errors.
Example
Context: "He said: 'Lowe was a brilliant, kind fellow who never sought the limelight... and 60 years on from Everest his achievements deserve wider recognition."
Gold annotation: "60 years on from"
Model prediction: "60 years on" (missing "from")
Analysis: Both generate similar SCATE code, but the boundary difference affects evaluation. This suggests the model understands the temporal semantics but struggles with precise span detection, particularly for multi-wore prepositions.
E4 Structural Errors
Structural errors involve complex nested temporal expressions requiring compositional operators. These account for 10% of errors.
Example
"The season started about month earlier than usual, sparking concerns it might turn into the worst in decade"
Context:
Gold expression: "month earlier than usual, sparking concerns it might turn into the worst in a decade"
Gold SCATE:
Last (fnnrrrwwwaaaaaaooeeeeeeeaaaaaar shift=Peri (umit=NONTH)), shift=Perion (un (umit=DECADE))
Predicted: Only captures fragments ("a month earlier", "decade") separately
The model cannot recognize that these fragments form single complex compara- tive temporal expression requiring nested operators.
Analysis:
F,5
Operator Confusion
Operator confusion occurs when the span is correctly identified but the wrong SCATE operator is selected. These represent 5% of errors.
Example
Context: "Mr. Obama said later at news conference in Amman..."
Gold expression: "later"
Gold SCATE: After (interval==Iteevval..... shift-None)
Predicted SCATE: Next
(....), shift=None)
Analysis: Both After and Next operators indicate future time, but After is more appropri- ate for indefinite future references while Next implies the immediate next occurrence. This reflects the subtle semantic distinctions between SCATE operators.
E.6 Granularity Errors
Granularity errors occur when the model represents temporal expressions incorrect levels of detail. These account for 5% of enrors.
49

---

Example
Context: "One exception was the swine flu pandemic of 2009-2010, when 348 children died."
Gold expression: "2009-2010"
Gold
SCATE:
Between (
end_ [ed__intervallYee (digits=21)))))))) start_ inc_iiiinddeddrr.. end_included-Truss)
Predicted SCATE: Year (drigits===00)
Analysis: The model loses the year range information and represents only the first year. The
gold annotation requires both 2009 and 2010 to be fully included (spanning to 2011-01-00 but the model only captures 2009, demonstrating granularity error where critical temporal scope is lost.
E7 Implications and Future Directions
Our error analysis reveals that the primary challenge lies in span recognition rather than SCATE code generation. Once temporal expression is correctly identified, the model generally produces appropriate SCATE code. The high proportion of missed expressions (70%) suggests that improving temporal expression recognition represents the most promising direction for future work, either through better training data, architectural improvements, or specialized span detection modules. The remaining 30% of errors related to boundaries, structure, and operator selection could potentially be addressed through more comprehensive training examples covering edge cases and rare compositional patterns.
50


Reviews:
[{"review_id": "SDKFt5kcH4", "reviewer": "Reviewer_zNnx", "summary": "Summary\n- The authors develop a python library 'SCATE' for time normalization using an existing research paper- Sematically Compositional Annotation of Temporal Expressions (Bethard et al 2016). They utilize the framework outlined in Bethard et al to develop code representations. Using an existing dataset (TempEval 2013), they implement LLM-based methods including data augmentation  to explore the extraction of time normalized information.", "questions": "- Figure 1 is vague and terse. The inputs and outputs to the LLM could be better outlined.\n- Which task dataset (A or B or C) in TempEval2013 was used for benchmarking? Description in lines 247-261miss that information. Were the methods outlined in the paper relevant? Were they tested before using this LLM-based approach?\n- Table 1 seems ambiguous. why weren't the performance of prompting techniques outlined in table 2- interval few-shot, SCATE, measured? What type of prompting techniques were used.\n- Were there performance improvements in run-time using the proposed method. Were Xu et al and Lapara et al frameworks studied? LLMs are great to use. What are the advantages of using the authors' proposed method against theirs? \n- Appendix B and C outline the prompts that were studied. Clarification- was the first prompt the full markdown page (13-35) Was the length of the prompts an issue? What happened if a smaller prompt was provided? Was the complete Markdown file generated by the authors or were LLMs used to refine the prompt? \n - The performance on Tasks A, B and ABC in TempEval paper have methods outlined. how does the proposed method compare to these rule-based and DL-based methods work?", "limitations": "NA", "rating": 2, "confidence": 5, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 2, "clarity": 2, "significance": 2, "originality": 2, "strengths_and_weaknesses": "Strengths\n--\n- The manuscript reads well. There is detailed documentation for the implementation of the framework from Bethard et al including python class objects, functions. \n- The common ambiguities that arise from the framework are well documented in the appendix.\n\nWeaknesses\n--\nThere is limited novelty in the manuscript and several weaknesses.\n- There is no benchmarking of existing methods for time normalization against the proposed framework. (See questions)\n- There is limited experimentation on various prompting techniques and is restricted to 2. \n- The authors do not benchmark the LLM-based extraction method against baseline fine-tuning methods using BERT.", "was_revised": true, "final_justification": "As discussed in rebuttals/ back and forth - the lack of a baseline and incomplete evaluation seems to me be the major issue in this work. Plug and play LLM outputs are easy to generate outputs and performance numbers. However, the contribution needs to be substantial involving exploration of a hard problem with nuanced method exploration, findings and error analyses. The error analyses, additionally pointed by other reviewers was only performed on 20 samples. \n\nThe addition of baselines from prior work were added based on reviewer feedback (LSTM and rule-based). The performance run-times were added post reviewer feedback.", "rebuttal": "Thank you for your review. We appreciate your recognition of our comprehensive Python implementation of SCATE, the manuscript's clarity, and our documentation of framework ambiguities. We address your concerns below:\n\n**W1: No benchmarking against existing methods**\n\nDuring rebuttal, We have conducted comprehensive experiments comparing our method against existing approaches:\n\nNeural Parser (Xu et al., 2019) - The only publicly available SCATE-based system and the previous state-of-the-art: F1: 0.4317, Precision: 0.5677, Recall: 0.3482.\n\nThis system represents the best existing method for SCATE-based time normalization before our work.\n\nSUTime (Chang & Manning, 2012) - The widely-used timenorm system (for comparison with non-SCATE approaches): F1: 0.4510, Precision: 0.5838, Recall: 0.3674\n\nOur method (Qwen2.5-0.5B fine-tuned on augmented data) achieves: F1: 0.59,  Precision: 0.59, Recall: 0.59, representing a 36.7% F1 improvement over the previous best and only available SCATE implementation (Neural Parser; Xu et al., 2019).\n\nThis is a significant advancement for SCATE-based time normalization. We emphasize that before our work, researchers had only one option for SCATE-based normalization (Xu et al., 2019), which required complex multi-stage processing. Our end-to-end approach not only outperforms it substantially but also provides a simpler, more deployable solution. We will add these comparisons to the revised manuscript.\n\n**W2: Limited experimentation on prompting techniques**\n\nWe respectfully clarify that our primary contributions are:\n1. Novel formulation of time normalization as code generation\n2. Complete Python implementation of the SCATE framework - the first publicly available executable SCATE library\n3. Large-scale augmented dataset (8,583 validated examples) generated through our approach\n4. End-to-end trainable system that achieves state-of-the-art results\n\nAll code, data, and models will be made publicly available upon publication.\n\nPrompting serves as a tool for data augmentation and model comparison, not as our core innovation. We have already designed comprehensive and detailed prompts (Appendix B, 23 pages) that effectively capture SCATE's complex semantics, enabling LLMs to generate executable code for a library they have not seen during pre-training. \n\nThe effectiveness of our approach is demonstrated by:\n- Successfully generating 8,583 valid SCATE code examples from 10k sentences\n- Training a 0.5B (BERT size) model that outperforms both its teacher model (Claude 3.7) and all existing baselines\n\nWe welcome specific suggestions on additional prompting techniques that would strengthen our evaluation, but emphasize that our contribution lies in the overall framework rather than prompt engineering.\n\n**W3: No comparison with BERT baseline**\n\nWe would like to clarify that BERT is primarily a classification model designed for sequence labeling/classification tasks. For time normalization, BERT would require: (1) a sequence labeling layer for span detection, (2) additional components for linking expressions, and (3) a separate normalization module. This makes direct comparison inappropriate.\n\nOur Qwen2.5-0.5B model (similar size to BERT-large) is a decoder-only transformer specifically suited for generation tasks. It performs end-to-end time normalization in simple forward pass, making it different from BERT's classification paradigm.\n\n## Responses to Questions:\n\n**Q1: Figure 1 clarity**\n\nWe clarify that Figure 1 illustrates the SCATE annotation schema. Figure 2 provides the complete system overview with clear input/output examples (bottom of figure). The left side shows input (text + DCT), and the right side shows output (SCATE code + execution results). We will add clearer labels in the revision.\n\n**Q2: TempEval-2013 dataset details**\n\nAs stated in lines 247-254, we use documents from TempEval-2013 with SCATE annotations (not the original ISO-TimeML Tasks A/B/C). We use the SCATE annotations from the official SCATE annotation repository, containing 557 training and 313 test examples with complete SCATE annotations.\n\n**Q3: Table 1 clarification**\n\nAs described in lines 282-284, Table 1 uses our SCATE prompt method. The purpose (line 279) is to evaluate whether state-of-the-art foundation models can perform time normalization using our comprehensive SCATE prompt. We show training set results in Table 1 to compare foundation model capabilities, then evaluate the best model (Claude 3.7 and GPT 4.1 ) on the test set in Table 2 to avoid overfitting. We will clarify this in the revision.\n\n\n**Q4: Runtime advantages**\n\nOur method offers significant runtime advantages:\n\n- Neural Parser (Xu et al. 2019): Complex multi-stage pipeline with character-level LSTM (very slow), plus rule-based linker and Scala-based normalizer\n- Our method: Simple forward pass through a 0.5B model (BERT-sized)\n\nOn long texts, our transformer-based end-to-end model is orders of magnitude faster than character-based LSTMs (well-established in literature). Additionally, our model is 1000x smaller than Claude 3.7, enabling practical local deployment.\n\n**Q5: Prompt engineering details**\n\nThe prompt in Appendix B is the complete markdown prompt used in our experiments. \n\nWe performed extensive prompt tuning; shorter prompts (especially with fewer examples) led to performance degradation on the training set.\n\nThe prompt was manually designed with assistance from Copilot during development.\n\nWe will clarify these details in the revision.\n\n**Q6: Comparison with TempEval methods**\n\nAs mentioned above, we use documents from TempEval-2013 but with SCATE annotations, not the original ISO-TimeML annotations. The original TempEval tasks (A/B/C) target different objectives with ISO-TimeML schema, making direct comparison inappropriate. Our work specifically addresses the more expressive SCATE framework.\n\nWe hope these clarifications address your concerns. We are committed to improving the manuscript based on your valuable feedback."}, {"review_id": "TWYkQvFQ3b", "reviewer": "Reviewer_wavY", "summary": "The authors present a novel formulation of the time normalization task as a code generation task. They contribute a comprehensive python library for executing the existing SCATE framework, which represents temporal expressions using temporal operators. They then investigate the use of large language models to generate SCATE code within their novel python library, and present an analysis of errors made by their best-performing model.", "questions": "* (See weakness #1) Were there any attempts to evaluate time expression identification and code generation separately?\n* Why are results so much worse on the test set? If I'm understanding correctly, Claude 3.7 + SCATE Prompt achieves 0.52 F1 on the test set, and 0.66 F1 on the training set. If this is due to block sampling in the creation of the TempEval-2013, this should be mentioned briefly in the manuscript. If the authors hypothesize that this is due to training data contamination, perhaps this should be noted in the manuscript as well.\n* Would it be possible to use existing time normalization systems (based on the ISO-TimeML framework) as additional baselines for this test set? That would further the argument for the necessity of the SCATE framework made on lines 25-37.", "limitations": "Yes", "rating": 5, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 4, "clarity": 4, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths:\n* The proposed SCATE Python library is extensive, and a valuable resource to the community.\n* The author's design of the SCATE library is well-suited for their downstream LLM code generation goal, as their class and operation names are semantically meaningful and likely to be interpretable by LLMs.\n* The ultimate goal of having a small model for both time expression extraction and SCATE code generation is well-motivated, and results present a solid baseline upon which future work can improve.\n* The evaluation of LLM performance is solid, with an interesting error analysis.\n\nWeaknesses:\n* The decision to jointly extract time expressions and generate SCATE code with one LLM pass needs more motivation, and perhaps an additional experimental result. While the authors offer that span recognition may be a direction for future work on lines 335-338, it's worth noting that techniques for extraction tasks with LLMs are generally improving (see 1, 2). It seems appropriate to evaluate whether using a specialized prompt for LLM time expression extraction and then generating SCATE code separately would further improve performance (albeit at the cost of an additional model pass), especially since this appears to be a source of frequent errors (see lines 324-326).", "was_revised": true, "final_justification": "* The proposed SCATE Python library is extensive, and a valuable resource to the community.\n* The author's design of the SCATE library is well-suited for their downstream LLM code generation goal, as their class and operation names are semantically meaningful and likely to be interpretable by LLMs.\n* The ultimate goal of having a small model for both time expression extraction and SCATE code generation is well-motivated, and results present a solid baseline upon which future work can improve.\n* The evaluation of LLM performance is solid, with an interesting error analysis.\n* The authors resolved each of my concerns in their rebuttal, including additional experiments furthering their motivations, and seem to have also addressed other reviewer concerns.", "rebuttal": "Thank you for your positive review and recognition of our contributions, particularly the value of our SCATE Python library and the solid baseline we establish. We address your concerns below:\n\n**W1: Joint extraction vs. separate extraction, Q1: Separate evaluation attempts**\n\nOur end-to-end approach is motivated by both practical and technical considerations:\n\nPractical motivation: Time normalization is often an upstream task in large-scale applications. For example, when processing millions of documents to build temporal knowledge graphs, a two-stage pipeline significantly increases complexity and reduces efficiency. Single-model inference is crucial for production deployments.\nExperimental validation: During the rebuttal period, we tested a two-stage approach using the CC-News + Training Set as training set:\n\n- Stage 1: Train BERT-base for time expression extraction\n- Stage 2: Train Qwen for SCATE code generation\n- Results: F1: 0.2490 (vs. 0.59 for our joint model)\n- Critical failure: 251/313 expressions missed (80% miss rate)\n\nWhile we acknowledge this BERT model here wasn't heavily tuned and more NER-specific data could help, the fundamental issues remain:\n\n- Error propagation: Missed expressions cannot be recovered in stage 2\n- Semantic coupling: Expression boundaries often depend on their SCATE interpretation (e.g., \"the past three summers\" - the full phrase is needed to understand it's a time expression), while separate extraction may miss context\n- Deployment complexity: Maintaining two models with different architectures\n\nOur joint approach leverages SCATE semantics during extraction, leading to better recognition and normalization. We agree specialized extraction techniques are promising for future work, particularly continued large-scale data generation to improve end-to-end models in this area. We will add these experiments and discussion to the manuscript.\n\n**Q2: Train vs. test set performance gap**\n\nThe performance difference is primarily because our prompt development relied on training set experiments to ensure fair comparison across models. The test set remained completely untouched to prevent overfitting. This leads to all LLMs show better training set performance. We will clarify this in the manuscript.\n\n**Q3: ISO-TimeML baselines**\n\nDuring the rebuttal, we added comparisons with SUTime (ISO-TimeML-based) and Xu et al. (2019) (the previous best SCATE-based system) to provide a clearer baseline for SCATE performance:\n\n- SUTime (ISO-TimeML-based): F1: 0.4510\n- Xu et al. (2019) (SCATE-based): F1: 0.4317\n\nOur method achieves F1: 0.59, demonstrating 30.8% improvement over SUTime and 36.7% over the previous best SCATE system. Our analysis reveals that our method can identify and normalize significantly more compositional time expressions compared to ISO-TimeML-based SUTime, leading to better performance.\n\nThank you again for your constructive feedback. We will incorporate these clarifications and experimental results in our revision."}, {"review_id": "nGUlTAYMWP", "reviewer": "Reviewer_YsgP", "summary": "This paper presents a novel approach to time normalization by reformulating it as a code generation problem following the SCATE framework. Traditional time normalization approaches that are based on ISO-TimeML schema struggle with complex temporal expressions like event-relative or compositional phrases. The presented method addresses this by implementing a fully executable SCATE Python library that translates temporal expressions expressed as text into structured and interpretable Python code, which then gets executed to produce deterministic normalized time normalization.\n\nContributions of this paper include:\n- It implements SCATE as a Python library, enabling deterministic execution of normalized time intervals;\n- It proposes data augmentation by using LLMs to generate SCATE code from text following a well-crafted prompt, creating over 8,000 new annotations of text-code pairs;\n- It presents empirical results of fine-tuning a small-scale model (Qwen2.5-0.5B) on the augmented data, showing that such a model can outperform the LLMs used for data generation and providing further analysis.", "questions": "As I mentioned, a main weakness of this paper is that the experiment section lacks thoroughness. My questions below are mainly around a result of that:\n- How does the proposed method compare to previous methods in a similar evaluation setting?\n\n- The authors show that in order for the 0.5B to learn the task, the augmented data (8k+) has to be used with the training set (300 examples), or otherwise the performance is close to zero. This suggests some data efficiency issues that can be addressed with options below. Have these been explored?\n  * efficient fine-tuning methods (LoRA), which typically works better with less data;\n  * using code-finetuned checkpoint instead of general instruction-tuned model.", "limitations": "yes", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 3, "significance": 2, "originality": 3, "strengths_and_weaknesses": "Strengths:\n- The method is original and has novelty according to the related work discussion. The idea of formulating time normalization as a code generation problem makes a lot of sense (i.e., the proposed python implementation essentially serves as a DSL for the time normalization task). This said, I am not very familiar with related work so cannot judge with confidence if the authors have missed important related work.\n- The paper is presented well and is very easy to follow and understand.\n- The empirical results are overall positive, showing that the approach is promising. The derived data as well as the model can be a useful resource for the community.\n\nWeaknesses:\n- The biggest weakness of this work is that the experiment section is brief and not particularly thorough, leaving some questions unanswered. As an example, it is hard to know how this method compares to previous work in a similar evaluation setup. I'll include more thoughts in the questions section below.\n- The problem being studied is relatively niche and is only impactful to a small community, limiting its overall significance.\n- Some in-depth analysis with examples can be provided to help the readers better understand the behaviors and limitations of the model.", "was_revised": true, "final_justification": "After reading the authors' response, I have adjusted my overall score from 3 to 4. As mentioned in my original review, the original version of the manuscript was weak because of its brief experiments, lack of insightful analysis, and relatively niche focus compared to other papers with broader audience and impact. The authors' response have improved the analysis part of the paper, and partially improved the thoroughness of its experiments. My concern on its niche focus remains and I do still think the experiments can be made even more extensive with more comparisons, therefore I am giving an overall rating of 4 (borderline accept).", "rebuttal": "Thank you for your review and constructive feedback. We appreciate your recognition of our novel approach and the potential value of our resources to the community. We address your concerns below:\n\n**W1: Limited experimental evaluation and comparison with previous work**\nDuring the rebuttal period, we conducted additional comparisons.\n\nExisting SCATE-based system:\n- Neural Parser (Xu et al., 2019) - The only publicly available SCATE implementation before our work: F1: 0.4317, Precision: 0.5677, Recall: 0.3482\n\n- SUTime (ISO-TimeML-based system): F1: 0.4510, Precision: 0.5838, Recall: 0.3674\n\nOur method:\n\n- Qwen2.5-0.5B + CC-News + Training Set: F1: 0.59, Precision: 0.59, Recall: 0.59\n- 36.7% improvement over the previous SCATE state-of-the-art\n- 30.8% improvement over SUTime\n\nThese results demonstrate that our approach significantly outperforms existing methods in comparable evaluation settings. We will add these comparisons to the revised manuscript.\n\n**W2: Data efficiency issues**\n\nDuring the development, we explored several strategies:\n\n1. Different fine-tuning approaches: We experimented with LoRA during development. However, we observed that LoRA produced similar results to full fine-tuning, particularly because our model is already quite small (0.5B parameters). Given the minimal difference and the simplicity of full fine-tuning for such a small model, we opted for full fine-tuning in our final experiments.\n2. Model selection rationale: We also explored code-pretrained models during development. However, we found that small code-specific models like Qwen2.5-Coder struggled significantly with temporal expression identification, leading to numerous missed time expressions before even attempting SCATE generation. This resulted in severe performance degradation (more than 0.2 F1 score drop). The issue appears to be that code-pretrained models, while excellent at code generation, lack the natural language understanding capabilities needed for identifying temporal expressions in text. Since our task requires both strong NLP capabilities (for span identification) and code generation abilities, we found that general instruction-tuned models like Qwen2.5-0.5B-Instruct provide the best balance. We acknowledge that exploring larger code-specific models or hybrid approaches could be valuable future work, but for our goal of deployable small models, the general instruction-tuned model proved most effective.\n\n\n**W3: In-depth analysis and examples**\n\nWe conducted detailed error analysis on our best model's predictions. Here are specific examples illustrating the main failure modes:\n\n1. Missed expressions (70% of errors): These are the most critical failures where the model completely fails to identify annotated time expressions:\n\n- Example: \"We estimated we could do it in 100 days, and we got across on the 99th day.\"\n - Time expression: \"99th day\"\n - Gold: `Nth(shift=Repeating(unit=DAY), index=99)`\n - Predicted: Missing\n - Analysis: The model struggles with ordinal expressions embedded in narrative contexts.\n\n- Example: \"This flu season started in early December...\"\n - Time expression: \"This flu season\"\n - Gold: `This(interval=Interval.of(2013, 3, 22), shift=Repeating(unit=None))`\n - Predicted: Missing\n - Analysis: Abstract temporal concepts like \"season\" without explicit calendar anchors are challenging.\n\n2. Boundary errors (10% of errors): The model identifies temporal expressions but with incorrect boundaries:\n\n- Example: \"He said: 'Lowe was a brilliant, kind fellow who never sought the limelight... and 60 years on from Everest his achievements deserve wider recognition.'\"\n - Gold annotation: \"60 years on from\"\n - Model prediction: \"60 years on\" (missing \"from\")\n - Both generate similar SCATE code but the boundary difference affects evaluation\n - This suggests the model understands the temporal semantics but struggles with precise span detection\n\n3. Structural errors (10% of errors): Complex nested temporal expressions requiring compositional operators:\n\n- Example: \"The season started about a month earlier than usual, sparking concerns it might turn into the worst in a decade\"\n - Time expression: \"month earlier than usual, sparking concerns it might turn into the worst in a decade\"\n - Gold: `Last(interval=Before(interval=Interval(...), shift=Period(unit=MONTH)), shift=Period(unit=DECADE))`\n - Predicted: Only captures fragments (\"a month earlier\", \"decade\") separately\n - Analysis: The model cannot recognize that these fragments form a single complex comparative temporal expression\n\n4. Operator confusion (5% of errors): Correct span identification but wrong SCATE operator selection:\n\n- Example: \"Mr. Obama said later at a news conference in Amman...\"\n - Time expression: \"later\"\n - Gold: `After(interval=Interval(...), shift=None)`\n - Predicted: `Next(interval=Interval(...), shift=None)`\n - Analysis: Both operators indicate future time, but \"After\" is more appropriate for indefinite future references while \"Next\" implies the immediate next occurrence\n\n5. Granularity errors (5% of errors):\n\n- Example: \"Mr Lowe also took part in the trans-Antarctic expedition of 1957-58\"\n - Time expression: \"1957-58\"\n - Gold: `Between(start_interval=Year(1957), end_interval=YearSuffix(interval=Year(1957), digits=58))` → spans 1957-1959\n - Predicted: `Between(start_interval=Year(1957), end_interval=Year(1958))` → spans only 1958\n - Analysis: The model misinterprets abbreviated year ranges, treating \"58\" as 1958 rather than understanding the convention that \"1957-58\" means 1957-1958 inclusive\n\nWe will add this detailed analysis with examples to the revised manuscript to help readers better understand the model's capabilities and limitations.\n\n**Additional clarifications on significance of the problem**\n\nWhile time normalization may appear to be a niche problem, it is actually a fundamental building block that quietly powers many critical real-world systems:\n\n- Clinical decision support: Accurate interpretation of expressions like \"take medication three times daily for two weeks\" or \"symptoms started 3 days post-surgery\" can be life-critical\n- Legal document analysis: Misinterpreting \"within 30 days of receipt\" vs \"30 days after receipt\" in contracts can have million-dollar consequences\n- Financial systems: Trading algorithms and regulatory compliance depend on precise temporal reasoning for transaction windows and reporting deadlines\n- Question answering: Any system answering \"when\" questions requires robust time normalization as a core component\n\nThe challenge is that these applications often fail silently when time normalization is incorrect: a QA system simply returns wrong dates, a clinical system miscalculates medication schedules. Our work provides the first publicly available, executable implementation of the most expressive temporal framework (SCATE), along with a large-scale dataset and deployable model. This enables researchers and practitioners to address complex temporal expressions that were previously impossible to handle systematically. In essence, time normalization is like parsing in NLP: a seemingly narrow technical problem that underlies countless applications. Our contribution makes this critical component more accessible and capable.\n\nThank you again for your constructive feedback. We will incorporate these clarifications and experimental results in our revision."}, {"review_id": "7xV6kuN0D1", "reviewer": "Reviewer_FPoj", "summary": "This paper proposes a novel end-to-end approach to time normalization by casting it as a code generation task within the SCATE (Semantically Compositional Annotation of Temporal Expressions) framerwork. The authors implement SCATE as a python library and show that large language models can generate valid code directly from natural language. They introduce a data augmentation pipeline in which LLMs generate annotated examples that are automatically validated through code execution. Using this synthetic data, they fine-tune a smaller, local model and report that it outperforms the LLMs originally used to generate the training data. Overall, the work presents a scalable, interpretable, and efficient method for handling complex temporal expressions.\n\nThe authors propose an innovative data augmentation strategy where LLMs generate synthetic annotated data (sentence, temporal expression, SCATE code) that is validated through runtime execution of the code, ensuring correctness. They demonstrate that a small, locally deployable model (Qwen2.5-0.5B) fine-tuned on this augmented dataset can outperform the LLMs used for data generation, achieving competitive performance while being computationally efficient and interpretable.", "questions": "Have you considered decoupling span detection from code generation via a two-stage pipeline? Would introducing a lightweight span classifier before code generation improve performance and reduce missed expressions?\n\nDoes the framework work on non-english languages?\n\nCould your executable code generation approach extend to other semantic parsing or reasoning tasks such as event extraction? \n\nAny failure analysis on the discarded code samples that failed execution? \n\nAny biases from the LLM generated dataset?", "limitations": "The limitations in the paper are well-articulated, including:\n\nRestriction to TempEval-2013 for SCATE evaluation.\n\nLack of multilingual or open-domain benchmarks.\n\nHeavy reliance on proprietary LLMs for data generation.\n\nPerformance gaps in span detection.\n\nPending open-source release of code and datasets.", "rating": 4, "confidence": 3, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": 3, "clarity": 4, "significance": 3, "originality": 3, "strengths_and_weaknesses": "Strengths\n\n1. Methodological Innovation:\nThe formulation of time normalization as a code generation problem using executable SCATE operators is novel. By directly outputting executable code, the system offers clear interpretability and determinism, unlike black-box sequence-to-sequence models.\n\n2. Practical Implementation:\nThe authors fully implement SCATE as a Python library with composable, object-oriented design, making the semantics both human-readable and machine-executable. The paper carefully details the class structures for intervals, repeating intervals, periods, and operators, ensuring transparency.\n\n3. LLM-driven Data Augmentation with Validation:\nThe automatic data augmentation pipeline cleverly uses LLMs to generate large-scale annotated data, filtered via code execution to guarantee syntactic and semantic correctness. This reduces reliance on scarce expert-annotated datasets and improves scalability.\n\nWeaknesses:\nDataset and Domain limitations:\n\nThe approach is evaluated solely on the TempEval-2013 dataset. The paper does not address how the system performs in other domains or languages beyond english. \n\nThe system struggles with accurately identifying temporal expression spans. \n\nPublic release not available yet\n\nPaper does not explore open source LLM alternatives, focuses mainly on Claude and GPT-4.1", "was_revised": true, "final_justification": "The paper is a borderline accept due to the data limitations and the lack of experiments in an expanded the domain.", "rebuttal": "Thank you for your positive and constructive review. We greatly appreciate your recognition of our methodological innovation, practical implementation, and LLM-driven data augmentation approach. We address your concerns below:\n\n**W1: Dataset and domain limitations**\n\nWe acknowledge the limitation to TempEval-2013. Unfortunately, this is the only publicly available dataset with SCATE annotations. While medical domain SCATE annotations exist, privacy restrictions prevent access to the underlying text. \n\nHowever, our data augmentation method is domain-agnostic and can be applied to generate annotations for any domain. In fact, we successfully augmented news data (CC-News) in our experiments. Extending to more domains through automatic annotation is a key direction for future work.\n\n**W2: Span detection struggles**\n\nWhile span detection remains challenging, we emphasize that our method achieves state-of-the-art performance on this difficult task. During the rebuttal period, we conducted additional comparisons:\n\nExisting baselines:\n- Neural Parser (Xu et al., 2019) - The only publicly available state-of-the-art SCATE system before our work: F1: 0.4317\n- SUTime (ISO-TimeML-based): F1: 0.4510\n\nOur method achieves F1: 0.59 - a 36.7% improvement over the previous SCATE state-of-the-art and 30.8% over SUTime.\n\nThe span detection challenge is inherent to the complexity of temporal expressions, particularly:\n- Compositional expressions like \"the past three summers\" where understanding the full semantic scope requires compositional reasoning\n- Context-dependent boundaries where the same phrase may or may not be temporal (e.g., \"spring\" as season vs. mechanical spring)\n- Multi-span expressions that SCATE uniquely handles but are impossible in simpler frameworks\n\nOur end-to-end approach is the first to achieve robust performance on these complex cases without requiring separate models for recognition, linking, and normalization. While there's room for improvement, we've established a new state-of-the-art baseline. Further improving span detection through larger-scale data generation and better modeling of compositional semantics is a promising direction for future work.\n\nWe will add these comparisons and analysis to the revised manuscript.\n\n**W3: Public release**\n\nWe are fully committed to releasing all code, models, and datasets upon publication. This includes:\n- Complete SCATE Python library implementation\n- Fine-tuned Qwen2.5-0.5B model\n- 8,583 augmented training examples\n- Training and evaluation scripts\n\n**W4: Open-source LLM alternatives**\n\nWe would like to clarify that training and releasing an open-source small model (Qwen2.5-0.5B) is one of our main contributions. For data augmentation, we did explore open-source LLMs from the Llama family, but their performance was significantly below GPT-4.1 and Claude. However, our method is model-agnostic and will benefit from improvements in open-source LLMs.\n\n### Questions:\n\n**Q1: Two-stage pipeline for span detection**\n\nOur end-to-end approach is motivated by both practical and technical considerations:\n\nPractical motivation: Time normalization is often an upstream task in large-scale applications. For example, when processing millions of documents to build temporal knowledge graphs, a two-stage pipeline significantly increases complexity and reduces efficiency. Single-model inference is crucial for production deployments.\nExperimental validation: During the rebuttal period, we tested a two-stage approach using the CC-News + Training Set as training set:\n\n- Stage 1: Train BERT-base for time expression extraction\n- Stage 2: Train Qwen for SCATE code generation\n- Results: F1: 0.2490 (vs. 0.59 for our joint model)\n- Critical failure: 251/313 expressions missed (80% miss rate)\n\nWhile we acknowledge this BERT model here wasn't heavily tuned and more NER-specific data could help, the fundamental issues remain:\n\n- Error propagation: Missed expressions cannot be recovered in stage 2\n- Semantic coupling: Expression boundaries often depend on their SCATE interpretation (e.g., \"the past three summers\" - the full phrase is needed to understand it's a time expression), while separate extraction may miss context\n- Deployment complexity: Maintaining two models with different architectures\n\nOur joint approach leverages SCATE semantics during extraction, leading to better recognition and normalization. We agree specialized extraction techniques are promising for future work, particularly continued large-scale data generation to improve end-to-end models in this area. We will add these experiments and discussion to the manuscript.\n\n**Q2: Non-English languages**\n\nYes, the framework is language-agnostic. As long as SCATE annotations are designed for the target language, our approach can be applied. The Python library and code generation method work independently of the input language.\n\n**Q3: Extension to other tasks**\n\nAs demonstrated in an exsiting paper \"A Dataset and Evaluation Framework for Complex Geographical Description Parsing\", similar operators (Union, Intersection) apply to geo-normalization tasks. Our executable code generation approach can be readily extended to any semantic parsing task with compositional semantics, including event extraction, spatial reasoning, and logical form generation.\n\n**Q4: Failure analysis on discarded samples**\n\nDiscarded samples primarily failed due to:\n\nSyntax errors:\n- Missing parentheses: `Year(2023` instead of `Year(2023)`\n- Undefined variables: Using `Months` instead of `MONTH` enum\n- Invalid Python syntax: Malformed string literals or incorrect indentation\n\nSemantic errors:\n- Invalid operator combinations: `Next(shift=Period(...))` when Next requires a Repeating shift\n- Incorrect parameter types: `Repeating(unit=DAY, value=\"Monday\")` instead of numeric value\n- Incompatible nesting: `This(interval=Period(...))` when This requires an Interval\n\nRuntime errors:\n- None value operations: Attempting arithmetic on underspecified expressions\n- Invalid date operations: `Interval.of(2023, 14, 1)` with month 14\n- Infinite loops in repeating intervals without proper bounds\n\nThese failures demonstrate our validation mechanism's effectiveness: only code that is both syntactically correct and semantically meaningful passes through, ensuring high-quality training data. We will include this analysis in the revised manuscript.\n\n\n**Q5: Biases in LLM-generated data**\n\nWe tested our augmented dataset using the `vector-institute/Llama3.2-NLP-Newsmedia-Bias-Detector` model. The analysis found no biases in the generated temporal expressions.\n\nThank you again for your constructive feedback. We will incorporate these clarifications and experimental results in our revision."}]

Author rebuttal:

Meta-review: (a) **Summary of Scientific Claims and Findings**

The submission introduces a new semantic-parsing view of time-expression normalization: instead of predicting ISO-TimeML strings or rule IDs, the model is trained to generate executable Python “code” that instantiates the SCATE (Semantically Compositional Annotation of Temporal Expressions) operators.  

• A complete, fully executable SCATE Python library (first of its kind) that turns code into concrete time-interval objects, enabling automatic self-validation.  
• A LLM prompting recipe that converts raw sentences into SCATE code; the generated code is executed at data-generation time to filter out ill-formed examples, yielding 8583 high-quality synthetic training instances.  
• A 0.5B-parameter, locally deployable decoder model (Qwen2.5-0.5B) fine-tuned on the augmented corpus achieves F1 = 0.59 on the held-out test set, compared with 0.43 (Xu et al., 2019; LSTM pipeline) and 0.45 (SUTime; ISO-TimeML).  
• The fine-tuned model runs 31.7x faster than the Xu et al. LSTM pipeline.  

(b) **Strengths**

1. **Executable resource** – The open-source SCATE library, plus 8.6 k validated examples and trained weights, will be immediately reusable.  
2. **Conceptual novelty** – Casting time normalization as *code generation* elegantly unifies span discovery, composition, and execution in a single forward pass. Although this is not completely novel in the era of LLMs, it is indeed novel for this task.
3. **Empirical gains & speed** – Clear state-of-the-art F1 (+14 pp absolute) and >30× inference speed-up over the only prior SCATE baseline.  

(c) **Weaknesses / Missing Elements**

1. **Limited evaluation breadth** – Only English SCATE-annotated TempEval-2013 is used; no cross-domain or multilingual evidence.  
2. **Baseline coverage still imperfect** – A T5-style seq2seq baseline is promised but not yet included in the camera-ready.
3. **Modest conceptual delta vs. Bethard et al. (2016)** – Some of our reviewers view the work as an engineering realisation rather than a fundamentally new theory.

(d) **Decision and Justification**

**Recommendation: Accept as a poster.**

Most reviewers (wavY = 5, YsgP = 4, FPoj = 4) find the contribution solid and useful; one reviewer (zNnx = 2) objects to missing baselines and limited novelty. The authors substantially mitigated those concerns during rebuttal by:

• Adding Xu et al. LSTM, SUTime, BERT span-detection + code-gen, and runtime comparisons.  
• Committing to include a T5 baseline and to foreground statistical tests and error analysis in the main text.  
• Clarifying that the “code-generation” formulation yields both higher accuracy and greatly simplified deployment.

While the experimental scope is still narrower than ideal, the executable library, validated dataset, and demonstrated performance bump constitute a tangible advance for temporal NLP and will likely catalyse follow-up work.

(e) **Discussion & Rebuttal Period Summary**

• **Reviewer zNnx (rating 2→2):**  
  – Requested strong baselines (BERT, T5), runtime numbers, statistical tests, deeper error analysis, and clearer figures.  
  – Authors added Xu/SUTime numbers, BERT two-stage results (F1 0.25), 31.7× speed figures, bootstrap CIs, a 5-category error taxonomy, and fixed Figure 2 bug; promised T5.  
  – I weigh zNnx’s methodological vigilance highly, but after additions the core criticism (absence of baselines) is partly resolved.

• **Reviewer wavY (5):**  
  – Sought motivation for joint span+code generation and clarification of prompt construction.  
  – Authors ran a two-stage BERT→Qwen experiment (F1 0.25) showing large drop vs joint; will describe prompt design in Sec. 4.2.  
  – Reviewer satisfied and kept strong-accept.

• **Reviewer YsgP (3→4):**  
  – Concerned about shallow experiments and niche impact.  
  – Added baselines and in-depth error examples alleviated experimental concern; impact concern remains but rating raised to borderline-accept.

• **Reviewer FPoj (4):**  
  – Wanted multi-domain evaluation and analysis of discarded samples.  
  – Authors provided failure-case taxonomy and argued domain-agnostic augmentation; reviewer kept borderline-accept.

Overall, the discussion led to meaningful manuscript improvements, and consensus now leans toward acceptance, with the caveat that the final revision must make the following changes:

1. Include the promised T5 baseline and highlight runtime & significance tests in the main body.  
2. Improve Figures 1–2 captions and explicitly define all evaluation metrics.  
3. Add the detailed error analysis and limitations to the discussion section.

Below are some suggestions from the reviewer which I'm copying as-is:
> Describe clearly the modifications/similarities of the code generation method with SCATE proposed by Bethard et al. (perhaps, visually in figure 1)

> Clearly indicate the inputs and outputs to the LLM in text (section 3.1) and visually in figure 2.

> Evaluation- explain what a 'gold standard triplet' means in section 4 (line 256). The paper includes a exact match performance evaluation, which is great. However, in my experience with LLMs, it may be possible to include a relaxed evaluation scheme based on error analyses - i.e., if there were issues with only generating the syntax but the expressions were correctly normalized. This needs an error analyses of more than 20 samples that the paper includes (line 322). I find this to be a lack of depth and lets do it depending on if reviewer asks .
Include samples sizes in table 1 and 2 for which the models were evaluated on.
Decision: Accept (poster)