Both parsers answer a bare day word with that day at the current minute, so "на
завтра" set a reminder at 01:38, the minute he happened to be speaking. The gate
is textual now: NamesAnHour reads the sentence, and the slot stays empty when
nobody said an hour.
Beside it, NamesAnInterval and HourIsAmbiguous, which the owner's commit rule
reads. "на" joins "в" as a frame around a spoken hour in both parsers, a clock
keeps its meaning with a full stop after it, and the stub applies a day word and
a part-of-day qualifier from anywhere in the sentence rather than only from the
token after the hour.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
At 21:12 "напомни мне завтра в семь позвонить маме" confirmed a reminder for
21:12 tomorrow. The hour was dropped and the wall clock carried onto the named
day. She did not ask; she named a time nobody gave her, on a path that fires.
A bare "напомни в семь" declines correctly, so adding "завтра" turned a decline
into an invented answer.
dateparser only reads a bare hour when it carries a qualifier or a colon.
"завтра в 7" keeps the current clock and "завтра в 7 часов" is read as seven
hours from now, which moves the day as well. English "at 7" fails identically,
so this is not a Russian defect and both prepositions are rewritten.
The script now gives it the colon: "в 7", "в 7 часов" and "at 7" become
"в 07:00" beside the existing утра/вечера rewrites. A duration is untouched,
because "через 2 часа" has no preposition to match, and so are "в 7:30",
"в 30 минут" and "в 2026 году".
The stub parser has always read the token after the day word, so the floor was
right and the production parser was not. No test on the stub could have caught
this. The four new cases are in TestPythonDateParser, which runs where
dateparser is installed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SoL7EBdYC5Mhz3DJd49GJy
At 14:41 "напомни в половине первого пообедать" was set for 12:30 the same
day, two hours gone, and confirmed as "напомню сегодня в 12:30". dateparser
is handed PREFER_DATES_FROM future and does not apply it to an HH:MM time on
today's date. parseClock in the stub has always rolled forward, so the two
parsers disagreed and the production one was the wrong half.
rollPastClockForward runs on the python result. Only a bare clock rolls: a
sentence naming its day keeps it, so a deliberate "сегодня в 12:30" stays
where he put it, and past by a day or more is not a clock resolved onto today.
NamesADay reads weekdays by lemma, the relative day words and the month names,
all from the lexicon.
Measured against real dateparser in a venv: "в половине первого" 05 Aug 12:30
to 06 Aug 12:30, "в 12:30" the same, "сегодня в 12:30" unchanged, and the
relative and named-day cases unchanged.
Left open: a reminder he places in the past is still accepted silently. Saying
the hour has gone is a phrasing gap, not this fix.
"напомни мне позвонить маме в семь вечера" answered "не получилось разобрать
время напоминания", while "в 19:00" set the reminder. Reminders arrive through
speech, and speech says the hour in words, so this was the ordinary case
failing and the typed one working.
SpellOutDigits rewrites a spoken number as digits, but only when a time word
stands beside it — "в три часа" becomes "в 3 часа" and "купить три яблока" is
left alone. Both parsers see it: dateparser already rewrites "7 вечера" to
"7 pm" and never saw a digit to rewrite, and the stub floor now reads the
qualifier itself.
PythonDateParser shells out to python3 with the dateparser library for
full natural-language date/time extraction. Two-step approach:
1. search_dates() finds the date substring in surrounding text
2. parse() re-parses the substring for correct time resolution
Russian time qualifiers (утра/вечера/дня/ночи) are pre-processed to
AM/PM before parsing — dateparser drops them during substring extraction.
Falls back to StubDateTimeParser when python3 or dateparser isn't
available (graceful degradation, no hard runtime dependency).
Dockerfile updated: python3 + dateparser==1.4.1 in runtime stage.
claude
kami