Conversation
A minimal AbstractCapability subclass that injects the current date/time into the system prompt via get_instructions(), with optional get_current_time tool. Configurable timezone and strftime format. Closes #23 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Invalid IANA timezone names now raise a ValueError with a helpful message and examples, rather than letting a raw KeyError propagate from ZoneInfo. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
DouweM
requested review from
Kludex,
adtyavrdhn,
dmontagu,
dsfaccini and
samuelcolvin
as code owners
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
|
|
||
| Returns a string like:: | ||
|
|
||
| The current date and time is: 2026-04-02T20:30:00Z (Wednesday, April 2, 2026) |
There was a problem hiding this comment.
🟡 Docstring example shows wrong day of week (Wednesday instead of Thursday)
The docstring example at line 27 claims April 2, 2026 is a "Wednesday", but it is actually a Thursday. The code itself uses strftime("%A") so it produces the correct day at runtime, and the test at tests/test_knows_current_time.py:40 correctly asserts "Thursday". This makes the docstring inconsistent with both the code's actual output and the tests.
| The current date and time is: 2026-04-02T20:30:00Z (Wednesday, April 2, 2026) | |
| The current date and time is: 2026-04-02T20:30:00Z (Thursday, April 2, 2026) |
Was this helpful? React with 👍 or 👎 to provide feedback.
| format: str = '%Y-%m-%dT%H:%M:%SZ' | ||
| """``strftime`` format string for the datetime.""" |
There was a problem hiding this comment.
🚩 Default format string includes literal 'Z' (UTC designator) that is misleading for non-UTC timezones
The default format is '%Y-%m-%dT%H:%M:%SZ' which includes a literal Z at the end — the ISO 8601 UTC designator. When a user configures KnowsCurrentTime(tz='America/New_York') without also changing format, the output will be e.g. 2026-04-02T16:30:00Z which falsely claims the time is UTC. The LLM would then interpret this as UTC rather than Eastern time.
This is not a runtime crash, and the default tz='UTC' + default format combination is internally consistent, so the defaults work correctly together. However, users who only customize tz will get semantically incorrect ISO 8601 output. Consider either documenting this limitation clearly, or using %z in the format to auto-append the correct offset (e.g. -0400), or programmatically adjusting the suffix based on the timezone.
Was this helpful? React with 👍 or 👎 to provide feedback.
Audit vs prior art: KnowsCurrentTimeWorth adding now:
Follow-up opportunities:
|
DouweM
removed request for
Kludex,
adtyavrdhn,
dmontagu,
dsfaccini and
samuelcolvin
1 participant
Summary
KnowsCurrentTime, a minimalAbstractCapabilitysubclass that injects the current date/time into the system prompt viaget_instructions()tz(IANA timezone, default UTC),format(strftime string), andinclude_tool(optionalget_current_timetool)pydantic_harnesspackage:from pydantic_harness import KnowsCurrentTimetzdatadependency for cross-platform timezone supportpydantic-ai-slimto git main branch (capabilities API not yet released to PyPI)Closes #23
Test plan
🤖 Generated with Claude Code