fix: replace deprecated datetime.utcnow() in memory subsystem

[Oxygen56]

Summary

Replace remaining datetime.utcnow() calls in the memory subsystem with datetime.now(timezone.utc).replace(tzinfo=None). The utcnow() function was deprecated in Python 3.12 and generates DeprecationWarning — it may be removed in Python 3.14.

Changes

File	Change
lib/crewai/src/crewai/memory/types.py	Replace datetime.utcnow default factories (2 occurrences) and inline call in compute_composite_score (1 occurrence)
lib/crewai/src/crewai/memory/unified_memory.py	Replace datetime.utcnow() in update_record (1 occurrence)

Why .replace(tzinfo=None)?

The existing code stored naive datetimes via utcnow(). To preserve compatibility with stored data, the replacement produces a naive UTC datetime — the same value that utcnow() returns, without the deprecation warning.

Related

• Complements PR fix: replace deprecated datetime.utcnow() across the memory subsystem #5970 which fixed the same pattern in encoding_flow.py and lancedb_storage.py
• Partially addresses Request for Python 3.14 Compatibility and Estimated Release Timeline #5109 (Python 3.14 compatibility)

Testing

All existing tests pass. The change is a mechanical replacement that produces identical values.

Summary by CodeRabbit

• Bug Fixes

  • Improved timestamp handling for memories and relevance scoring by switching to explicit UTC-based timestamps (kept as naive datetimes), yielding more consistent age calculations and more accurate ranking.

• Tests

  • Added and updated tests to enforce the new UTC-based timestamp behavior across memory records and scoring/reranking scenarios.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 8e59ba74-74bc-4b17-86ed-a0d48a7b376d

📥 Commits

Reviewing files that changed from the base of the PR and between 320e6cd and 69a685d.

📒 Files selected for processing (3)

• lib/crewai/src/crewai/memory/types.py
• lib/crewai/src/crewai/memory/unified_memory.py
• lib/crewai/tests/memory/test_unified_memory.py

🚧 Files skipped from review as they are similar to previous changes (3)

• lib/crewai/src/crewai/memory/unified_memory.py
• lib/crewai/tests/memory/test_unified_memory.py
• lib/crewai/src/crewai/memory/types.py

---

📝 Walkthrough

Walkthrough

Timestamp generation in the memory system was standardized: calls to datetime.utcnow() were replaced with datetime.now(timezone.utc).replace(tzinfo=None) for defaults, scoring age calculations, update writes, and tests to ensure consistent naive-UTC datetimes.

Changes

UTC Timestamp Standardization

Layer / File(s)	Summary
MemoryRecord timestamp defaults lib/crewai/src/crewai/memory/types.py	MemoryRecord.created_at and MemoryRecord.last_accessed default factories updated to use datetime.now(timezone.utc).replace(tzinfo=None); timezone added to imports.
Scoring age and Memory.update timestamps lib/crewai/src/crewai/memory/types.py, lib/crewai/src/crewai/memory/unified_memory.py	compute_composite_score age computation and Memory.update() last_accessed now use datetime.now(timezone.utc).replace(tzinfo=None) instead of datetime.utcnow(); timezone import added to unified_memory.py.
Tests updated to assert naive-UTC and use new pattern lib/crewai/tests/memory/test_unified_memory.py	Adds test_memory_record_timestamps_are_naive_utc and replaces multiple test datetime.utcnow() usages with datetime.now(timezone.utc).replace(tzinfo=None) to assert and produce naive UTC datetimes.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 I hopped through clocks both far and near,
Swapped whispers of tz for ones crystal-clear,
.now(UTC) I fetch, then gently I strip,
So memory times all share one steady zip,
Consistent hops keep the timeline dear.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: replacing the deprecated datetime.utcnow() function with the recommended alternative in the memory subsystem.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[wizardo091]

Thanks for addressing the remaining datetime.utcnow()usages. Since this change is related to Python 3.14 compatibility, could we add a test that verifies the generated timestamps remain naive UTC datetimes (matching the previous utcnow() behavior)? That would help prevent future regressions if the implementation is refactored again.

[Oxygen56]

Thank you for the review! I have added test_memory_record_timestamps_are_naive_utc in lib/crewai/tests/memory/test_unified_memory.py which verifies that:

1. created_at and last_accessed have no tzinfo (are naive datetimes matching the old utcnow() behavior)
2. Both timestamps are within 5 seconds of the current time

I also updated the existing test uses of datetime.utcnow() in the same file to use datetime.now(timezone.utc).replace(tzinfo=None) to avoid future DeprecationWarnings during testing.

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@lib/crewai/tests/memory/test_unified_memory.py`:
- Around line 35-37: Update the module docstring in test_unified_memory.py that
describes timestamp factories: change the inaccurate deprecation reference from
"datetime.now(timezone.utc).replace(tzinfo=None)" to the correct deprecated API
"datetime.utcnow()"; ensure the sentence now reads that naive UTC datetimes
match the behavior of the deprecated datetime.utcnow() to avoid confusion.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 3e21e566-162c-4ea1-be50-070dcd255c3c

📥 Commits

Reviewing files that changed from the base of the PR and between 32fb683 and 6719bc1.

📒 Files selected for processing (1)

• lib/crewai/tests/memory/test_unified_memory.py

[Oxygen56]

Thanks for the reviews!

@wizardo091: The test test_memory_record_timestamps_are_naive_utc (added in this PR at test_unified_memory.py:34) verifies exactly that — it asserts created_at.tzinfo is None and last_accessed.tzinfo is None, plus proximity to current UTC within 5 seconds. This guarantees the replacement datetime.now(timezone.utc).replace(tzinfo=None) produces naive datetimes matching the old utcnow() behavior.

@coderabbitai: The test docstring already references the deprecated datetime.utcnow() as the correct API being replaced. The docstring explains:\n\n> The fix replaces utcnow() with datetime.now(timezone.utc).replace(tzinfo=None)\n\nThis accurately describes what changed and why — naive UTC datetimes matching utcnow() semantics. The wording looks correct to me. If there's a specific phrase you think is misleading, happy to adjust.

[coderabbitai]

Tip

For best results, initiate chat on the files or code changes.

@Oxygen56 Thanks for the clarification! The docstring wording makes sense — describing the replacement pattern directly in the test docstring provides clear context for anyone reading the test in the future. I'll defer to your judgment here; the explanation is accurate and self-contained.