This article explains the logic TimeMeaning uses when it processes a pasted time reference. Transparency about interpretation logic is part of the product's core design — a tool that explains its reasoning is more trustworthy than one that simply produces an answer.
Step 1: Tokenisation
The pasted text is scanned for tokens that could represent time information: digits in time-like patterns, timezone abbreviations, day names, month names, relative phrases like "next" or "tomorrow," and standard format indicators like "am," "pm," "UTC," and "Z."
Example input:
"Let's connect at 10am CST next Wednesday — works for LA morning?"
Detected tokens:
10am, CST, next Wednesday, LA morning
Step 2: Structural parsing
Detected tokens are assembled into candidate time expressions. The parser identifies that 10am CST next Wednesday is a single time reference with three components: a time of day (10:00), a timezone abbreviation (CST), and a relative date reference (next Wednesday).
LA morning is identified as a second implicit time reference — a request to express the first time in the context of Los Angeles.
Step 3: Ambiguity detection
Each component is checked for ambiguity. CST is flagged as ambiguous — it maps to both Central Standard Time (UTC−6) and China Standard Time (UTC+8). next Wednesday is evaluated relative to the current date to produce a specific calendar date. LA morning is resolved to America/Los_Angeles.
If the ambiguity cannot be resolved from context (for example, if there are no other signals indicating whether the sender is in the US or China), the tool flags the ambiguity explicitly and asks the user to clarify before proceeding.
Step 4: DST resolution
Once the timezone and specific date are known, the tool looks up whether DST is active for that timezone on that date. For the resolved Wednesday date, Central Standard Time in the US may or may not be active depending on whether the date falls before or after the March DST transition. The correct offset is applied to the resolved time.
Step 5: Output generation
The resolved time is expressed in: the original timezone with offset, UTC, and the requested secondary timezone (Los Angeles). Each step of the reasoning is included in the output — which timezone was assumed, whether DST is active, and what the date is in each location. The ISO 8601 canonical form is produced for reference.
What the tool does not do
TimeMeaning does not use a general-purpose large language model to produce its output. The interpretation pipeline is deterministic — the same input will always produce the same output. The tool does not learn from pasted text, does not retain input between sessions, and does not use statistical inference to guess at ambiguous inputs. When something is ambiguous, it is flagged, not guessed.